Blockchain solutions for financial services and other transactions-based industries

ABSTRACT

A system and a method for creating a holistic, flexible, scalable, confidential, low-latency, high-volume, immutable distributed ledger for the financial services and other industries. The system allows a scalable blockchain solution with respect to accessible memory requirements of distributed ledgers or distributed databases with confidentiality in the shared records as well as accommodating low-latency, high-capacity transaction capabilities. The method includes a fundamental, generic, logical representation of financial services life-cycles transactions in terms of variable sets of four simple, sequential components. The optimal process generates a self-validating, variable n-dimensional, multi-hash-linked, interdependent distributed ledger that allows the individual network participants to recreate the ledger without having to refer to or confirm with other network participants.

RELATED PATENT APPLICATIONS

This application claims priority to U.S. Provisional Application No.62/379,771 filed on Aug. 26, 2016 and U.S. Provisional Application No.62/259,108 filed on Nov. 24, 2015.

BACKGROUND

This disclosure generally relates to distributed ledger computersystems. More particularly, the technology herein relates to computersystems and processes that interface using blockchain technology.

Bitcoin is a crypto currency which is transacted on a securedecentralized ledger that is distributed throughout its open network.The ledger is known as the blockchain and it allows participants in thenetwork to transact bitcoin without the need for a trusted third party,such as a bank. Separately, it also prevents double spending, stealingand the forging of value. The financial services industry, beyondlooking at the potential of crypto currencies, has recently turned itsattention to using the blockchain ledger separate from bitcoin or othercrypto currencies and applying it to other processes and products.

The blockchain is a data structure that stores a list of transactions,forming a distributed electronic ledger that records transactionsbetween source identifiers and destination identifiers. The transactionsare bundled into blocks and every block (except for the first block)refers back to or is linked to a prior block in the chain. Computernodes maintain the blockchain and cryptographically validate each newblock and the transactions contained therein. The integrity (e.g.,confidence that a previously recorded transaction has not been modified)of the entire blockchain is maintained because each block refers to orincludes a cryptographic hash value of the prior block. Accordingly,once a block refers to a prior block, it becomes difficult to modify ortamper with the data (e.g., the transactions) contained therein. This isbecause even a small modification to the data will affect the hash valueof the entire block. Each additional block increases the difficulty oftampering with the contents of an earlier block. Thus, even though thecontents of a blockchain may be available for all to see, they becomepractically immutable.

The attraction of the blockchain process is significant. It offers alow-cost distributed-transaction record solution. The near-real timespeed of the transactions, the ease of transacting between parties andthe nature of the technology also offer the potential of wholly newbusiness models and practices.

However, the solutions within the financial services industry utilizingblockchain have tended to be parochially developed on a product orfunctional basis. Some are only focused on payments. Others are lookingat specific product areas such as syndicated loans, credit defaultswaps, interest rate swaps and repo. Although complex in theirderivation, structures and pricing, the consistent properties of allthese transactions are that they are: over the counter (OTC)transactions, unregistered securities, low volume per transacting partyand in total, and predominantly involve only payments. Therefore, theseproducts represent the simplest use cases for utilizing distributedledger technology on the bases of scalability, flexibility andviability. Further ideas have focused on the ‘ledger’ of distributedledger and therefore have been dominated by clearing or record keepingsolutions.

Bitcoin and the blockchain open-source code, scripts, protocols anddistributed ledger were defined by a whitepaper released in December,2008. Since then the open-source decentralized crypto currency networkhas expanded to greater than 14 MM bitcoin and is transacted globally 24hours per day, seven days per week. The code, scripts and protocols areenhanced and accepted on an open-source code basis. So new code willonly be adopted by various nodes if it has a demonstrated value. Tomaintain integrity and predictable execution times, the script languageused is a primitive and simple language with no logical loops and simpleread, write, delete functionality with conditional flow control.

Very simply, bitcoin represents a value that is transferred within thisblockchain network. The ledger is updated and distributed to all membersof the network so before transacting with another party, the availablevalue of bitcoin of the payer (deliverer) can be verified. The securetransaction process and update to the ledger allows the payee (receiver)to have that value of bitcoin added to his/her total value of bitcoin tobe spent in the future.

This security of the transaction and recording mechanism allows for thetransfer of value without the need of a trusted third party such as abank. Records of available value recorded against an accountidentification can also be locked by an “encumbrance” controlled by theowner. The value can only be released by that owner.

The security is provided by two mathematically driven techniquescombined in a novel way: public key encryption and secure hashing. Theuse of these techniques underscores the fundamental properties of thebitcoin network and blockchain functionality.

Public key (or asymmetric) encryption is a secure means of encryptingtransactions which makes it (based on the computing time necessary)impossible to decrypt without the correct keys. Through a complexmathematical relationship (utilizing elliptical curves) a “private”encryption key can be chosen and a “public” key derived. Note: Theprivate key cannot be derived from the public key. The relationshipbetween the keys is such that whichever one is used to encrypt amessage, the other is needed to decrypt the message.

This means a person in possession of a set of keys can publish thepublic key to allow counterparties to send him/her a message that onlyhe/she can decrypt with the private key. In reverse, the owner of thekeys can send a message, which is equivalent to a signature or proof ofidentity, by encrypting it with the private key. Anyone can decrypt thatmessage with the sender's public key and know it must be valid as it canonly come from a person who knows the private key.

By this means, people can send secure messages to and from each otherwith their respective public keys and the only requisite forconfidentiality is that the individuals do not disclose theirindividual, separate and unique private keys. This is in fact thetechnique used to encrypt and send email across the internet securely.

Secure hashing is a complicated mathematical process of turning anypiece of binary data into a finite-digit hexadecimal (i.e. base 16)number. For the current, published Secure Hashing Algorithm standard(SHA 256), the finite number of digits is 64. With 64 digits havinganyone of 16 (i.e., 2⁴) values (0-9 and a-f), there are 2²⁵⁶ (i.e.,2^((4×64))) possible hashes. Note: The hashing process cannot bereversed to generate the original data. For more security, a hash can bemade of a hash multiple times or hashed with further data.

What the final hash represents is a secure way of verifying originaldata. If you have the original data in binary form, you can recreate thesame hash from the same technique. If you obtain a different hash, thenthe original data is incorrect or has been tampered with.

This is the technique used for verifying passwords over the internet. Awebsite stores a hash of a user's password. Upon typing the password, itis hashed and compared to the stored hash for validation. With thisprocess, the password is not stored anywhere for corrupt individuals toobtain it; the hash is a useless piece information except for confirminga correctly hashed password. The only way a user can be defrauded is bydisclosing his/her password or having it stolen.

In order to securely record and transfer bitcoin without doublespending, stealing or forging of value, a process combining publicencryption and secure hashing is used. With bitcoin, there is not theconcept of a balance like a bank account. The distributed ledger has arecord of the entire users' unspent transaction outputs (abbreviated asUXTO) from prior transactions. Each user (or technically the node onwhich they transact) has a copy of the distributed ledger so beforeaccepting a transfer of bitcoin, the recipient can confirm the payer'sUXTO. The confirmation of the payer (being who they say they are) isboth through the public encryption of the transaction matching thepayer's public key and the payer, optionally, being able to unlock theunspent value with an encrypted encumbrance. The cryptographicallyconfirmed transaction creates a hash of the transaction data (includingthe reference to the ledger blocks which proved the UXTO) and issubmitted to the transaction pool. At this point, the transaction isdeemed contractually entered into but it is not able to be referenceduntil it is recorded on the blockchain ledger.

The process of recording transactions to the block is referred to in thebitcoin network as “mining”. In order to create a new block a group oftransactions, up to 1 MB of memory have to be grouped and theircollective data securely hashed referencing the prior blockchain block'shash. This then creates a new hash for the new block to be referenced bythe next future block. In this way a chain of blocks is formed whichsequentially reference each other according to the encrypted transactioncontent. As an added complication to the process, the final hash of thenew block has to be less than a defined target value. This is referredto as the ‘difficulty’ of the required hash. Consequently, the blockhash has to be created (i.e., hashed) with a variable known as a“nonce”. Because the hashing process is one way and the correct noncecannot be reverse calculated from a reverse hashing process, the minershave to guess the nonce that will give them a final block hash that isless than the defined difficulty. The guessing process for each blocktakes on average 10 minutes. The open-source code within the bitcoinnetwork tracks the resolution time over a set number of cycles and canvary the difficulty to ensure new blocks are created every ten minuteson average. With the increase in computing power being applied to themining process, the setting of the level of difficulty for the hash hashad to evolve.

The process of creating the next block is effectively a competitionbetween the miners to find the correct hash that is below the level ofdifficulty. As the miners do not necessarily pick the same transactionsto encapsulate in a block, they are not all solving the same problem. Inorder to create a fraudulent transaction (double spending, stealing orforged value) a miner would have to change a real transaction or createa false one while maintaining the integrity of all the linked hashes,which is virtually impossible. The nature of the completion anduncertain selection of chose transactions means any one miner does nothave control of which transactions make it to the block. A badtransaction would be identified and rejected by other nodes and notaccepted by the network. The only way to overcome the network would beto have greater than 51% of the network's computing power—a costly andextremely difficult undertaking. Even if the miner could createfraudulent transactions, it would be on an immutable distributed recordfor the whole network to see and eventually find.

This type of block processing is called “proof of work” as the minershave to work to create the block. There are other methods of creatingblocks in other crypto currencies. “Proof of consensus” requires atleast 51% or a defined, greater majority of the network to accept a newnode before it is validated. “Proof of stake” skews the creation ofblocks to miners with greater value in the network, which means in orderto overcome the network, the miner would need greater than 51% of thenetwork's value.

Having created a new block, the node will start communicating it toother nodes, which will only accept it if the hashing matches thereferenced blocks, the transaction details and the level of difficulty.However, if the new block meets the criteria, the nodes will accept thenew block and communicate it to other nodes. So there is a period ofdissemination of the new block to the network. Transactions not includedin the new block rise in priority to be included in the next block to becreated.

In summary, the blockchain is a peer-to-peer network-based, distributed,self-referencing, single-chain, single-record ledger for the purpose ofrecording transfers of value and unspent value. The ledger storesrecords from the very first transaction until the latest record. Thismeans the distributed ledger, of which every node has a copy, is acontinuous and expanding record of all transactions. The code, scriptsand protocols used in the network are developed in an open-source codingenvironment. The transactions and unspent value of all participants arerecorded against their account identification numbers. Apart from theanonymity of the account number, all records are accessible to allparticipants. The control and integrity is maintained by: (1) all usersbeing able to reference prior blocks to prove their own or theircounterparties unspent balances; (2) only the user with the unspentvalue being able to prove ownership through a digital signature thatvalue to be spent; (3) the two parties agreeing to a transaction throughpublic encryption and submitting a transaction to a pool to be processedreferencing the prior blocks validating the unspent value; (4) amechanism, such that the transactions are added in blocks to thesingle-chain, distributed ledger by referencing the prior block's hashand creating a new block with a new hash for the next block, whichreferences the transactions in the block; (5) the integrity of eachblock's creation is maintained through various methods that include:competition, consensus or value held; (6) ultimately a majority of theother nodes have to accept any new block for it to be widely available;and (7) the new block forms part of the expanding immutable record to bereferenced for future transactions.

For all crypto currencies, from an accounting perspective, thetransactions on the blockchain are simple, single transfers of value ofa balance-sheet-equity-based (i.e., fully-paid-for) asset. The cryptocurrency cannot leave its network. It can only be transacted within itsnetwork amongst participating users.

From an understanding of blockchain process used with bitcoin and thesimple nature of the recorded transactions, the following are a list ofchallenges which have to be overcome or solved in order to utilizeblockchain or distributed ledger processes within the financial servicesindustry.

(A) Open-Source Code with No Loops:

The language used for blockchain applications have been predominantlydeveloped within an open-source process. While controlled in its ownself-policing way, this methodology may not be acceptable for theregulated entities or compliant with the laws and rules within thefinancial services industry. The challenge is the paradox of creating adecentralized code and ledger which cannot be developed through opensource. Also the blockchain code language is relatively primitive in thesense that only simple sequential functions of reading, writing,stacking and conditional flow can be performed. Although it hasconditional flow, it does not have any loops. The simplicity of the codeprevents processing roadblocks and infinite loops while reducingpossible risks to the ledger's integrity. Any blockchain solutions forthe complexity within the financial services have to do so with theprimitive, simple code.

(B) Continuous Record:

For crypto currencies there are hundreds of transactions per minute onone blockchain and there are concerns about the size and ever-growingmemory requirements for the continuous ledger that the nodes mustmaintain. Within the financial services across multiple securities,contracts and currencies, there are thousands of transactions per secondso it is infeasible to consider all nodes maintaining a continuousrecord of all transactions, any part of which may be referenced tovalidate a future transaction.

(C) Anonymity and Confidentiality:

With a distributed ledger, all nodes have a copy of all transactions andunspent value for all users. The only anonymity is derived from accountidentifiers being a non-descriptive number. However, once a user knowsanother user's identifier, he/she could recreate the complete activityand unspent value from the ledger records. Bitcoin has different methodsof pooling transactions or transferring histories to provide someconfidentiality but these techniques would be unacceptable to financialservice regulators. The network needs to be able to create aconfidential ledger that can still be referenced and confirmed by userstransacting with each other.

(D) Block Creation Methodology and Transaction Volumes:

There are multiple methodologies for creating blocks within a blockchainnetwork, the purpose of which is to maintain the integrity of the ledgerand prevent fraud. Within the financial services, the methodology has tobe able to cope with the transaction types, structures and requirementswhile also meeting the volume and capacity requirements of the industryand the speed requirements of algorithmic, high-frequency trading. Theinterests of all participants have to be aligned or incentivized in sucha way that the whole ledger is maintained equally with no bias.

(E) Contingent Transactions:

Current crypto currencies represent single transfers of value. Mosttransactions in the financial services involve contingent transactionssuch as deliver versus payment (DVP) or receive versus payment (RVP).This would require the network to be able to settle both simultaneouslyor such that one transaction cannot be reversed after the settlement ofthe other.

(F) Lending, Collateralized and Default Transactions:

Current crypto currencies utilize simple transfers of value. The userowns the currency or gives up that ownership through a transfer. Withinthe financial services industry, many of the currencies or securitiesare loaned and borrowed. Separately, other cash and securities may bepledged as collateral for various transactions. The blockchain processeshave to be able to transact, reflect and manage the life-cycle of thesetypes of transactions. Lastly, in the event of a default, any loan orcollateralized transactions will have to be resolved throughcredit-event-driven contracts and bankruptcy administration.

(G) Future-Dated, Payable or Short Transactions:

Current blockchain processes are based on concepts of delayed processingof transactions but these are about setting a future time for afully-paid-for transfer of value. Within the financial services manytransactions and contracts create individual or a series of future-datedtransactions which will create obligations on assets that the usersentering into the transactions might not yet own or may be contingent onfuture events (e.g., exchange-traded options where the option buyer hasthe right of exercise or allowing the contract to expire, unexercised atmaturity). In the process of market making or principal trading, abroker can sell an asset that has not been bought yet. With respect tovariable driven (e.g., future-dated derivative payments) or yet unknowntransactions (e.g., executed price for allocated trades), the amount tobe transferred will be unspecified. This capability has to be availableto process and record these types of transactions. Overall, the abovetransactions effectively require a transfer of value in the blockchainthat cannot be pre-referenced or pre-defined within the historicalledger, yet can ultimately be settled and recorded in a controlledprocess.

(H) Current Market Interfaces:

Whatever blockchain solution is created for whichever security orposition of value, that value will be transacted in the blockchainnetwork and in the current marketplace. The blockchain solution has toallow for its users to transact with the current world and be able totransfer value in and out of the network. With current blockchainsolutions, the crypto currencies exist and can only be transacted withintheir single blockchain networks.

(I) Interoperability:

Crypto currencies exist on distributed, single-record blockchains. Anysolution for the financial services will have to have a multi-chainsolution that allows the flexibility to add more and offerinteroperability between chains or networks.

(J) Regulatory, Risk and Accounting-Based Reporting:

Beyond the trading and record keeping of the financial services, eachparticipant and role has a plethora of obligations on how to record,monitor and report status to a series of defined status. The blockchainsolution will optimally cover these responsibilities. For all theprocesses not covered by the blockchain, interfaces and enterpriseplatforms will still be required.

There is a need for blockchain solutions that address one or more of theforegoing challenges to enable a distributed ledger for the financialservices and other industries.

SUMMARY

This disclosure is directed to a system and a method for creating aholistic, flexible, scalable, confidential, low-latency, high-volume,immutable distributed ledger for the financial services and otherindustries, which is functionally product, service and businessagnostic. The system allows a scalable blockchain solution with respectto accessible memory requirements of distributed ledgers or distributeddatabases with confidentiality in the shared records as well asaccommodating low-latency, high-capacity transaction capabilities. Themethod includes a fundamental, generic, logical representation offinancial services life-cycles transactions in terms of variable sets offour simple, sequential components. This approach allows greater processcontrol with less variability and the use of simpler, Turing-incompletecode within the network. The proposed approach disclosed in detail belowachieves its high-capacity and low-latency performance through optimalprocess design and optimal utilization of network and computinghardware. The optimal process obviates the need for independenttransaction validation techniques such as mining or network consensus bygenerating a self-validating, variable n-dimensional, multi-hash-linked,interdependent distributed ledger that allows the individual networkparticipants to recreate the ledger without having to refer to orconfirm with other network participants. The optimizing of network andcomputing hardware occurs by the originating participant technologyfocusing on creating, posting and broadcasting transactions only andrecipient participant technology focusing on receiving, validating andposting transactions only. The methods simplify and genericize the usecases and life-cycles in the financial services or other industries,which facilitates flexibility in dealing with any financial use case orlife-cycle within a Turing-incomplete coding method. Also, the systemand method allows processing of non-ledger referenced value tofacilitate market making, short sales, payable or future-datedtransactions (whether specified, unspecified or variable-driven),principal and agency execution, and pledge and loan transactions toallow financed and collateralized transactions. There is also amechanism for the controlled transfer of asset value in and out of thenetwork to allow settlements with current market practitioners or otherdistributed ledger networks. The participant and network data structurealso lends itself to consistent means for enriched data alignment forother downstream reporting requirements of the ledger data withoutoverloading the ledger itself.

The approach proposed herein comprises the following components: (a) autility-driven method of creating process and product building blocksreferred to herein as the “genome”; (b) a flexible, self-verifying,variable, n-dimensional ledger that is product and process-agnosticdistributed ledger network utility; and (c) a method to allow themanagement of distributed ledger or database memory through archivingand the controlled staging of transactions to cover all types oftransactions. The genome is a generic way of defining all financialservices, transactions, products and life-cycles through combinations ofpre-defined, parameter-driven sequential components. This allows thecomplexity of the financial services industry to be broken down intosimple components for ease of definition for workflow, product design aswell as technology requirements and coding. The simple nature of thesequential components or building blocks allows the distributed ledgernetwork code to be Turing-incomplete and therefore does not includeinfinite loops. The distributed ledger network utility (DLNU) works onnewly defined applications and techniques for blockchain technology andprocesses. Within the network's defined expanding structure, it has thepotential to transact, process and record all financial servicestransactions and functions across the entire trading, investment andinvestor life-cycles. The logical rollout evolution of capabilitiescreates the flexibility to subsume or retain links to legacy processesand technology. The method is by participant with a product-agnosticnetwork. Many current competing initiatives are rolled out by productwith a participant agnostic solution.

More specifically, the functionality of the genome and DLNU (to bedescribed in more detail later) enables a distributed ledger for thefinancial services and other industries which addresses the previouslydescribed challenges A through J, which blockchain solutions can besummarized as follows.

(A) Trusted Network and Genome-Derived Transactions and Scripts:

A trusted (private and permissioned) network initially with approvedcode enhancements is utilized. Transactions are defined for coding andscripts using the genome.

(B) Bifurcated Transaction Blockchain and Ownership Log:

The proposed blockchain solution provides a bifurcated daily transactionledger (that can be archived) and a continuous ownership log (that isvalidated daily) to create finite memory requirements. It usescontra-transactions which are broadcast independently by bothtransacting parties to control ownership log updates. (as used herein, a“contra-transaction” refers to a transaction involving two activeparties, each party having a respective perspective of thattransaction.) Each node will create and broadcast its transaction logledger while receiving and recreating the other node's transaction logledgers. The matched and validated contra-transactions will be the basisof ownership log updates. Each node will maintain and keep its own copyof the ownership log.

(C) Unique Dual Transaction and Ownership Identifiers:

For each transfer recorded on the ownership log, there will need to be a“Delivery” and “Receipt” record to be recognized. For confidentiality,each log item will have a coded and encrypted identifier which can beverified and decrypted with provided variables to prove identity ofownership. For security, each log record will also have a lockingencumbrance that can only be unlocked by the owner to allow the recordedasset value to be included in a script.

(D) Proof of Completeness and Consistency Using Fractal Lattices:

Each node will create and broadcast a single contra-transaction perblock with each block given a unique fractal lattice address and priortransaction hash-link cross referencing the fractal lattice address andhash-link of the other transacting party's node's contra-transaction.The variable, n-dimensional, fractal data structure and linkages providea means for independent nodes to recreate and validate the ledgerwithout the need to confer with other nodes or confirm the data with theoriginator. The independent fractal lattice transaction ledgers can berecreated at any node and the matched pairs of contra-transactionsprovide the justified updates to the ownership log. The fractal latticesand the ownership log are the self-validating, non-duplicative, completedistributed ledger. The computing power and network hardware are nowonly focused on generating, posting and broadcasting created, controlledtransactions or receiving, validating and posting received transactions.Apart from reducing transaction memory size and computational load, thisis the optimal design for capacity and throughput.

(E) Dependent Blockchains:

In accordance with some embodiments, independent “contingent”contra-transaction fractal lattice blockchain records are maintained bythe transacting parties' nodes for contingent transactions, which, whenmatched, allows both transacting parties' nodes to create two sets ofdual transactions (i.e. Delivery-Receipt and Receipt-Delivery) to therelevant fractal lattice-structured transaction logs and ownership logsfor the contingent assets. This controlled linkage of both legs to acodified blockchain record prevents a one-sided reversal.

(F) Lending and Pledging Logs:

In accordance with some embodiments, lending and pledging logs allowassets to be recorded via transactions to reflect loans and obligationsthat transfer ownership or record keeping custody without increasingtotal assets. Defaults can reverse transaction pairs without impactingother obligations or ultimate ownership.

(G) Unreferenced Asset Value Transaction Blockchains:

In accordance with some embodiments, unreferenced asset valuetransactions are created on a contingent blockchain record that onlygenerates contingent transactions upon validation of referenced assets.For unexecuted allocated trades or future-dated, currently unknownparameter-driven transactions, the amount to be transferred will beunspecified.

(H) “Airlock” Blockchain:

In accordance with some embodiments, a unique blockchain transaction log(i.e., a ledger named “Airlock”) will exist for the controlled recordingof transfers of value into and out of the network.

(I) Agnostic Architecture and Defined-Order Rollout Method:

The network architecture combined with the genome transaction definitionallows for new products and functionality blockchains to be added asthey are utilized. The defined-order rollout allows flexiblefunctionality span to be defined per user with application programminginterfaces (APIs) to legacy processes. The “Airlock” blockchaintransaction log allows transactions between the network and currentmarkets or other networks.

(J) Expanded Transaction Parameters:

The transaction logic for each blockchain can be expanded viaorigination script or post-record enhancement script to includeregulatory, risk and accounting-based parameters that can then beread/write functions instead of report generation or APIs to legacysystems. The creation of each node's transaction log and ownership logallows for ease of linking, enhancing or expansion of data for analysisor reporting that does not have to be broadcast to the network.

One aspect of the subject matter disclosed in detail below is a methodfor operating a distributed ledger system comprising a network ofmultiple nodes, comprising: (a) generating a first set of transactiondata for a transaction in a first node in the network, wherein thetransaction data of the first set comprises data identifying the firstand second nodes, data identifying an asset, data representing an amountof value and other data; (b) generating a second set of transaction datafor the transaction in a second node in the network, wherein thetransaction data of the second set comprises data identifying the firstand second nodes, data identifying the asset and data representing theamount of value and other data; (c) generating a first encrypted hash ofa message comprising the first set of transaction data in the firstnode; (d) generating a second encrypted hash of a message comprising thesecond set of transaction data in the second node; (e) sharing the firstencrypted hash with the second node; (f) sharing the second encryptedhash with the first node; (g) generating delivery contra-transactiondata for the transaction in the first node, which deliverycontra-transaction data comprises the first set of transaction data andthe second encrypted hash and does not identify the second node; (h)generating receipt contra-transaction data for the transaction in thesecond node, which receipt contra-transaction data comprises the secondset of transaction data and the first encrypted hash and does notidentify the first node; (i) broadcasting the deliverycontra-transaction data to the network; (j) broadcasting the receiptcontra-transaction data to the network; (k) receiving the broadcastdelivery and receipt contra-transaction data at a third node in thenetwork; (I) matching the broadcast delivery and receiptcontra-transaction data in the third node; (m) validating the deliverycontra-transaction data in the third node by decrypting the secondencrypted hash to generate a first hashed message, hashing the secondset of transaction data to generate a second hashed message, andmatching the first and second hashed messages; (n) validating thereceipt contra-transaction data in the third node by decrypting thefirst encrypted hash to generate a third hashed message, hashing thefirst set of transaction data to generate a fourth hashed message, andmatching the third and fourth hashed messages; and (o) posting thedelivery and receipt contra-transaction data to logs in the third node.The transaction is one of the following types: a transfer, a pledge, aloan, a contingent transfer, a short transfer, a short transfer fill, ashort contingent transfer and a short contingent transfer fill.

In accordance with one embodiment, each delivery transaction log has afirst fractal lattice structure comprising fractal lattice addresses andeach receipt transaction log has a second fractal lattice structurecomprising fractal lattice addresses, and the method further comprises:identifying a first next sequential fractal lattice address in the firstfractal lattice structure; hash linking the first next sequentialfractal lattice address to a fractal lattice address in a prior layer ofthe first fractal lattice structure; associating the deliverycontra-transaction data with the first next sequential fractal latticeaddress; identifying a second next sequential fractal lattice address inthe second fractal lattice structure; hash linking the second nextsequential fractal lattice address to a fractal lattice address in aprior layer of the second fractal lattice structure; and associating thereceipt contra-transaction data with the second next sequential fractallattice address. In one specific example, step (c) comprises hashing amessage comprising the first next sequential fractal lattice address, afirst node identifier, a second node identifier, an asset identifier andan amount of value and then encrypting the hashed message using aprivate encryption key of the first node, and step (d) comprises hashinga message comprising the second next sequential fractal lattice address,the first node identifier, the second node identifier, the assetidentifier and the amount of value and then encrypting the hashedmessage using a private encryption key of the second node.

The above-described method may further comprise maintaining a uniqueblockchain transaction log for the controlled recording of transfers ofvalue into and out of the network.

In accordance with one embodiment, the first and second nodescommunicate via scripts, and the method further comprises scriptbuilding and running processes which are programmed in machine-readablecode of four, parameter-driven sequential process components which aregenerically combined in various combinations to represent any financialservices transaction or life-cycle without the need for infinite loops.The four components are: (a) a single transfer of one asset; (b) anasset classification change; (c) a time-driven change in value; and (d)a contingent, dual asset, bi-directional transfer. The respectiveparameters for each sequential component are: (a) number, unit andvalue; (b) timings: single event, periodic events and multiplenon-periodic events; (c) generated events: data, date, state, choice andgain/loss; and (d) primary, secondary and tertiary assets.

Another aspect of the subject matter disclosed in detail below is adistributed ledger system comprising a network comprising first, secondand third nodes configured to perform operations (a) through (o) setforth above.

A further aspect of the subject matter disclosed in detail below is amethod for a multi-hash link, variable, n-dimensional self-validation ofconsistency and completeness on a distributed ledger or database for anetwork of multiple nodes for single or multiple parties utilizingmachine-readable code to record value, records or information and thetransfer thereof between the multiple parties participating in thenetwork on an immutable record, whereby updates to the ledger bymultiple parties utilizing multiple nodes update the ledger andbroadcast the changes via transaction data and the multiple nodesvalidate the integrity, completeness and consistency of the ledger withthe transaction data alone without the need to confer with any othernodes or parties, whether they instigated the transaction or not. Thetransaction data of any one node is sequenced utilizing a fractallattice pattern created by its own defined equation allowing multiplealgorithmically calculable, non-recurring, sequential, variable,n-dimensional branch locations to uniquely assign a data address forreferencing unique transaction data in a distributed ledger or databasefor a network of multiple nodes for single or multiple parties utilizingmachine-readable code such that the data's address is communicated andused by any other node in the network to recreate the data and uniqueaddress without the need to confer with the originating node or othernodes in the network. The fractal pattern chosen to create dataaddresses to be assigned is variable by a formula of a fractal patternand is varied from data period to data period as long as the chosenpattern is communicated to the multiple nodes and parties in the networkto allow them to recreate the structure without the need to confer withthe originating nodes or parties or other nodes or parties in thenetwork. In addition, a data set applied to the unique address is givena classification of “end” to mark the end of a fractal branch or “last”to mark a last transaction posted in a period so that the completenessof the data structure and addresses are communicated and used by anyother node in the network to recreate and confirm the completeness ofthe data structure and unique address without the need to confer withthe originating nodes or parties or other nodes or parties in thenetwork. This method further comprises hash-linking a data address to ahash of any prior utilized address in a structured or unstructured waywhich is referenced in the data address data such that when it iscommunicated to the network of multiple nodes for multiple parties, anynode recreates and validates the hash link to verify the consistency ofthe originating nodes data structure without the need to confer with theoriginating node or parties or other nodes or parties within thenetwork.

In accordance with one embodiment of the method described in thepreceding paragraph, every transaction in the network between two ormore parties transacting utilizes coded script and securely shares datato agreed script parameters and shares transaction security and linkingdata at one or more nodes to create contra-transactions that reflecttheir distinct obligations for transfers or contingent transfers suchthat the contra-transactions are linked, validated and matched tojustify the update of ownership data without the need to confer with theoriginating nodes or parties or other nodes or parties in the network.Across the network, two originating nodes generate distinct and uniqueprivate key encrypted hashes, whereby the hashes are created from a setof transaction data fields and transacting node identity is shared andrecorded by the originating nodes on a reciprocal transaction as a meansto link the contra-transactions and validate the identity of theoriginating nodes and prevent interference unless the two private keysof the originating nodes are known. Mathematical transformations of thetransacting parties public encryption key in conjunction withtransaction data and a random nonce create a unique, confidentialidentifier for every position on the distributed ledger or databaseownership log when it is created to be posted to the ownership logmaintained by every participating node on the network, thereby revealingthe identity of the transacting parties whenever the transaction dataand nonce are provided to a node which is independent of the nodes ofthe transacting parties. A further mathematical transformation of aunique identifier with transaction data and a random nonce may be usedto create an encumbrance for the value, records or information recordedon the distributed ledger or database ownership log such that the valuecan only be unlocked by the transacting party that knows the transactiondata and random nonce combined with the mathematical transformation.

In accordance with the embodiments disclosed in detail below, twotransacting parties via respective originating nodes process respectivecontra-transactions for a single asset transfer and then broadcast tothe distributed ledger or database network of multiple parties or nodes,whereby the contra-transactions can be matched and validated by themultiple nodes in the network to update their distributed ledgers ordatabases in the network to confirm the related update to the ownershiplog is staged to occur immediately or at a time or event-driven time inthe future whether the position transferred is a pledge or a loan, isledger referenced or unreferenced, is specified or unspecified, and isfuture-dated or variable dependent. In the alternative, two transactingparties via respective originating nodes process respective pairs ofcontra-transactions for contingent, bi-directional dual asset transferswhich are broadcast to the distributed ledger or database network ofmultiple parties or nodes, whereby the pairs of contra-transactions arematched and validated by the multiple nodes in the network to updatetheir distributed ledgers or databases of contingent transfers in thenetwork to confirm the related creation and processing of the two pairsof contra-transactions is staged to occur immediately or at a time orevent-driven time in the future whether the positions for either of thedual assets transferred are a pledge or a loan, are ledger referenced orunreferenced, are specified or unspecified, and future-dated or variabledependent position.

Other aspects of a distributed ledger for financial servicestransactions that utilizes blockchain technology are disclosed below.

BRIEF DESCRIPTION OF THE DRAWINGS

The features, functions and advantages discussed in the precedingsection can be achieved independently in various embodiments or may becombined in yet other embodiments. Various embodiments will behereinafter described with reference to drawings for the purpose ofillustrating the above-described and other aspects.

FIGS. 1 through 6 are flowcharts identifying steps of a genome scriptbuilding process in accordance with one embodiment.

FIGS. 7 through 12 are flowcharts identifying steps of a genome scriptrunning process in accordance with one embodiment.

FIG. 13 is a diagram identifying transfer entries in an ownership log inaccordance with one embodiment.

FIG. 14 is a diagram identifying contingent transfer entries in anownership log in accordance with one embodiment.

FIG. 15 is a diagram identifying pledge and pledge return entries in anownership log in accordance with one embodiment.

FIG. 16 is a diagram identifying loan and loan return entries in anownership log in accordance with one embodiment.

FIG. 17A is a diagram identifying ownership log entries for Airlocktransfer in.

FIG. 17B is a diagram identifying ownership log entries for Airlocktransfer out.

FIG. 18 is a diagram showing a fractal lattice self-defining andself-verifying process for simple fractal lattices constructed at twonodes that create the delivery and receipt contra-transactions for atransfer.

FIG. 19A is a diagram showing the process for digitally signing andverifying a delivery transfer contra-transaction.

FIG. 19B is a diagram showing the process for digitally signing andverifying a receipt transfer contra-transaction.

FIG. 20 is a flowchart showing a process for executing and recordingtransactions using multi-signature encrypted hashing in accordance withone embodiment.

FIG. 21 is a schematic illustrating the high-level components of theexecution and recording of a simple transfer process between two nodesconnected by a network in accordance with one embodiment.

FIG. 22 is a schematic illustrating the high-level components of theexecution and recording of a simple transfer process between nodesconnected by a network in accordance with another embodiment.

FIG. 23 is a schematic illustrating the high-level components of theexecution and recording of a contingent transfer process between twonodes connected by a network in accordance with one embodiment.

FIG. 24 is a schematic illustrating the high-level components of theexecution and recording of a short transfer process between two nodesconnected by a network in accordance with one embodiment.

FIG. 25 is a schematic illustrating the high-level components of theexecution and recording of a short contingent transfer process betweentwo nodes connected by a network in accordance with one embodiment.

FIG. 26 is a schematic showing an intra-day ownership validation processperformed by an independent node in accordance with one embodiment.

FIG. 27 is a schematic showing an inter-day ownership validation processperformed by a node in accordance with one embodiment.

FIG. 28 is a schematic showing interdependent blockchain linkagesbetween the ownership log of one node and the fractal lattice-structuredtransaction logs of itself and other nodes at two different times inaccordance with one embodiment.

FIG. 29 is a schematic illustrating future-dated period linkages linkingtransaction data in a fractal lattice-structured transaction log inaccordance with one embodiment.

FIGS. 30 through 37 are schematics illustrating respective workflows fordifferent types of transactions in a network comprising one node thatcreates the delivery contra-transaction, another node that creates thereceipt contra-transaction and an independent node that records thetransaction and balances in accordance with one embodiment. Theworkflows depicted include: asset transfer workflow (FIG. 30); assetpledge workflow (FIG. 31); loan process workflow (FIG. 32); contingenttransfer workflow (FIG. 33); short transfer workflow (FIG. 34); shortfill workflow (FIG. 35); short contingent transfer workflow (FIG. 36);and short contingent transfer fill workflow (FIG. 37).

Reference will hereinafter be made to the drawings in which similarelements in different drawings bear the same reference numerals.

DETAILED DESCRIPTION

Illustrative embodiments of a distributed ledger for financial servicestransactions that utilizes blockchain technology are described in somedetail below. However, not all features of an actual implementation aredescribed in this specification. A person skilled in the art willappreciate that in the development of any such actual embodiment,numerous implementation-specific decisions must be made to achieve thedevelopers specific goals, such as compliance with system-related andbusiness-related constraints, which will vary from one implementation toanother. Moreover, it will be appreciated that such a development effortmight be complex and time-consuming, but would nevertheless be a routineundertaking for those of ordinary skill in the art having the benefit ofthis disclosure.

The process, business logic and controls of the blockchain solutionswill now be described in general. The core component of the proposedblockchain technology, with respect to the business requirements, isthat the transacting parties (TPs) will be agreeing and broadcasting vianetwork nodes a sequential series of transactions as defined within theaforementioned “genome”. The genome consists of four sequentialtransactional components, specified by four categories of parameters.The four sequential transactional components are: (1) an asset transferA between two parties; (2) an asset classification change C; (3) a gainor loss G (i.e., time-driven increase/decrease in value (e.g., assetversus currency)); and (4) a contingent transfer T (i.e., a reciprocaltransfer of two assets between two parties). The parameters, for whichvarious combinations will exist for each sequential component are: (I)contractual elements: number, amounts and value; (II) timing: singleevent, periodic events and multiple events; (Ill) generated events:data, state, choice and gain/loss; and (IV) asset classification:primary, secondary and/or tertiary assets.

Any transaction within a financial services life-cycle consists of twocontra-transactions. A transaction could be either a transfer or acontingent transfer. A transfer is the fundamental transaction. Thecontra-transactions for a transfer are delivery versus receipt. A“contingent (bilateral, dual asset) transfer” (e.g., RVP/DVP or foreignexchange), while needing to be represented and controlled as a complete,self-contained transaction itself, is effectively two simultaneouscontra-transactions. The contra-transactions for a contingent transferare delivery versus receipt and receipt versus delivery. A “loan” is atransfer or a contingent transfer with a classification of the assetlent. A “pledge is a transfer or a contingent transfer with aclassification of the asset pledged.

For the above transactions, there will also be “short” versions, i.e.,the transactions without a ledger referenced value to transfer. Fortransactional components (3) and (4), there will be loan and pledge“return” transactions. Loans and pledges made versus cash or collateralwill be processed as contingent transfers with the loan or pledgedclassification in the received amount.

The agreement and mechanism for the execution of the transactions willbe achieved through Turing-incomplete shared-source code andnetwork-approved scripts. The implementation of this technology and codefunctionality can be refined over time. Taking this variability intoaccount, the following assumptions may be made:

(a) The execution of a transaction will occur outside the network. Thecommercial implementation of the blockchain technology envisages thatthe two parties will keep a private copy of digitally signed executionscross referenced to the confidential public record (which is theblockchain solution outlined in this disclosure), but the private copyprocess of the executed transactions is beyond the scope andconsideration of this functionality. A future state of this network,registered as an exchange, alternative trading system or electroniccommunication network, could provide execution capabilities directly asa component of its scripted and coded functionality. As a registereddepository, the network could potentially issue and perfect its owndigital securities and currencies.

(b) While the implementation of a distributed ledger does not require acentral intermediary, the initial commercial implementation of thistechnology will require a central utility for the purposes of holdingomnibus securities positions with a depository, sub-custodian ortransfer agent and cash with a bank or central bank. Note: Until adistributed network can perfect and service all types of securities andcash assets within its own network (e.g., bitcoin, Ether), this utilitywill be a requirement of all distributed ledger network solutions. Forthe purposes of transacting within the network, all functionality of theutility can be ignored and any transactions of value into and out of thenetwork need only be reflected by their record on the ledger in thesolution referred to herein as the “Airlock”.

(c) The process, business logic and controls utilizing a new distributedledger logic will replicate middle and back-office processing andcontrols, such as confirm/affirm, clearance and settlement.

(d) For the above, the logic disclosed herein shows a dependency on thereceiving TP (TP_(Rec)) confirming the delivering TP (TP_(Del)). Withthe nature of trading, this can be done electronically or at the pointof execution.

(e) While the high-level logic of the code and script-driven interactionbetween TPs is an outline, for the purpose of this functionality, itonly has to be considered from a sense of generating the standardizedgenome sequential components as it may ultimately take on many differentforms.

(f) The scripts will allow the TPs to agree and generate a sequentialset of the defined contra-transactions between each other and broadcastthem to the network.

(g) While the system and method disclosed herein incorporate a solutionfor a commercial implementation of broker fills (i.e., multiple marketexecutions to “fill” a client order) and fund manager allocations (i.e.,multiple “allocated” settlements against different accounts) for blocktrades, this disclosure predominantly focuses on single transfers andcontingent transfers.

(h) Post “execution”, the code and scripts will allow each of the TPsand their nodes to generate and share the common and distinct data ineach transaction to each other. The fractal lattice-driven,n-dimensional means to organize and link the distributed ledger data viaunique data addresses and hash-linking is the re-creatable record forthe other nodes.

(i) Each transacting party and its node can match the transaction dataand create and broadcast its contra-transaction to the network.

(j) Based on matched and validated copies of both contra-transactions,all nodes will be able to update their copies of the distributed ledgerand confirm accuracy, integrity, consistency and completeness.

(k) The records for the distributed ledger in the commercialimplementation of the solution will be segregated by node per asset orgroups of assets (e.g., index's, industry sectors, etc.). For thepurposes of this disclosure, the assumption will be that the recordswill just be segregated by node per single asset.

(l) While the secure recording and transfer of value is the firstcritical component of a market or of facilitating commercialtransactions, there are many downstream processes or obligations(regulatory-driven or otherwise) that are necessary as well. Theflexible, consistent and distributed data structure adopted hereinallows for further data enhancement and reporting to be easilyimplemented by adding fields to the current records or linking off-chaindata by the unique transaction and balance identifiers.

(m) For reflecting assets, the network will use agreed industry standardidentifiers. However, to reflect cash and currency transactions, theywill also be reflected as assets that all nodes in the network transact.

(n) The self-defining and self-validating nature of the distributedledger removes the need for consensus or puzzle solving and so focusesthe computing power of each node on processing and validatingtransactions. The only other communication within the network will be toidentify, resolve or broadcast status of incomplete or erroneoustransactions. While it is envisaged, that there may be sampleconfirmations of end of period (EOP) hashes, they are not required butmay be used as an additional control.

(o) In accordance with one commercial implementation, the designdisclosed herein can be implemented in a private, permissioned network.There will have to be an assumption of evolving standards and practicesagreed amongst the participating nodes, which can be used as anadditional means to limit bad behavior such as those used in stock orfutures exchanges.

(p) At the end of a transacting period, before shutting downtransmission of transactions, a node will mark its last transaction asits “last” or an empty (null) transaction as “end”, so any other nodewill then know its copy of that node's fractal lattice-structuredtransaction log is complete.

(q) After broadcasting and receiving all transactions to/from thenetwork, each node will hash its copies of the ownership logs andfractal lattice-structured transaction logs to the hash of the priorperiod's respective ownership logs and fractal lattice-structuredtransaction logs.

(r) The start-of-period (SOP) ownership log will start with the hashfrom the prior period's end-of-period (EOP) ownership log.

(s) Each fractal lattice-structured transaction log for a new periodwill start with a hash of the prior period's fractal lattice-structuredtransaction logs. The first transaction of the period, posted to FLAddress: 1, will be hash linked to that hash.

The process, business logic and controls of the blockchain solutions inaccordance with one embodiment will now be described in detail using theterminology listed in Tables 1 through 3.

TABLE 1 Terminology for General, Parties and Nodes TerminologyDefinition Transfer A simple transfer of one asset between two parties(e.g., payment or free delivery) DVP/RVP Deliver versus payment/receiveversus payment DVR/RVD Deliver versus receive/receive versus deliverContingent A simultaneous exchange of two assets between two Transferparties (e.g. DVP/RVP or FX) TP Transacting party Asset An asset used ina transfer Amt The amount of an asset in a transaction or ownership logposition record, recorded in the units in which the asset is transactedAsset_(AB) or One of two different assets in a contingent transferAsset_AB AssetB_(BA) or One of two different assets in a contingenttransfer Asset_BA TP_(DEL) or TP_Del Delivering transacting partyTP_(REC) or TP_Rec Receiving transacting party TP_(ABBA) or Contingenttransfer transacting party delivering Asset_(AB) and TP_ABBA receivingAsset_(BA) TP_(BAAB) or Contingent transfer transacting party deliveringAsset_(BA) and TP_BAAB receiving Asset_(AB) N_(DEL) or N_Del A node thatcreates the delivery contra-transaction in a transfer N_(REC) or N_Rec Anode that creates the receive contra-transaction in a transfer N_(ABBA)or N_ABBA The node that creates the contingent transfer for TP_(ABBA)N_(BAAB) or N_BAAB The node that creates the contingent transfer forTP_(BAAB) N_(IND) or N_Ind A node that is uninvolved in a particulartransaction but records transactions and balances for future use andreference Sk Secret or private encryption key Pk Public encryption keyEncrypted # or E# Standard, defined encrypted hash for defined fields,which are different for N_Del Tx_Del and N_Rec Tx_Rec⁽¹⁾ (see Table 2)Encumbrance This is a nonce or other mechanism to lock the value on theownership log (OL). Nonce This is a 64-digit hexadecimal numbergenerated by a hash or random number generator for use in theencumbrances or masking (i.e., making confidential) a TP's identity. SOPStart of Period. This is the beginning point where the OLs are hashed tothe prior period's EOP OL and there are no transactions created. EOP Endof Period. This is the point where transacting stops, the fractallattice-structured transaction logs are archived and OLs are hashed tocreate the SOP OL. Effectively this is the date flip mechanism. IDPIntra-Day Period. All time between SOP and EOP. ⁽¹⁾Note: The encrypted #can be sent without the “message” as per normal encryption protocol asit can be compiled from the select combined data fields after matchingTx_(DEL) and Tx_(REC) but only after both have been matched.

TABLE 2 Terminology for Transaction Logs Terminology Definition FLFractal lattice-structured transaction log utilizing a mathematical andsequential database data linkage and reference methodology FL ID Uniqueidentifier for a node's FL FL_(Address) or FL_Address A unique,mathematically and sequentially defined position within the structure ofthe FL FL_(Cntg) or FL_Cntg The fractal lattice used by each node torecord contingent transfers Fn The fractal number of the FL used#_(LINK) or #_Link Hash link of prior layer FL_(Address) to lower linkedFL_(Address) Tx Transaction (a transfer or a contingent transfer)Tx_(DEL) or Tx_Del Delivery contra-transaction for a transfer Tx_(REC)or Tx_Rec Reception contra-transaction for a transfer Tx_(DEL) # orTx_Del # A hash of the delivery contra-transaction details Tx_(REC) # orTx_Rec # A hash of the reception contra-transaction details Tx_(ABBA) orTx_ABBA Contra-transaction for contingent transfer transacting partydelivering Asset_(AB) and receiving Asset_(BA) Tx_(Del-AB) or Tx_Del-ABIndividual contingent transfer for delivering Asset_(AB) Tx_(Rec-BA) orTx_Rec-AB Individual contingent transfer for receiving Asset_(AB)Tx_(BAAB) or Tx_BAAB Contra-transaction for contingent transfertransacting party delivering Asset_(BA) and receiving Asset_(AB)Tx_(Del-BA) or Tx_Del-BA Individual contingent transfer for deliveringAssete_(BA) Tx_(Rec-AB) or Tx_Rec-BA Individual contingent transfer forreceiving Assete_(BA)

TABLE 3 Terminology for Ownership Logs Terminology Definition OLOwnership log - each node's database of holdings within an asset OL IDUnique ownership log identifier, assigned by the TP_(REC), to each“long” position recorded on the OL OL ID 1 Unique identifier assignedagainst each position or lot of an asset's value that a TP owns and willuse as TP_(DEL). A TP may have multiple unique OL identifiers per asset.OL ID 2_(Short) or OL ID 2_Short When a short transaction is enteredinto, the TP_(REC) will create a OL ID 2 for the position to be filled,which will be recorded on the FL_(Short) or FL_(Cntg). OL ID 2 Uniqueidentifier assigned by the TP_(REC) for the amount to be transferred andadded as a new record to the OL OL ID 3 Unique identifier assigned bythe TP_(DEL) for the net amount retained after the transfer and added asa new record to the OL OL ID n_(AB) or OL ID n_AB Any OL identifier forAsset_(AB) used in a contingent transfer OL ID n_(BA) or OL ID n_BA AnyOL identifier for Asset_(BA) used in a contingent transfer OL ID_(L) orOL ID_L OL identifier for a loaned position OL ID_(B) or OL ID_B OLidentifier for a borrowed position OL ID_(PLF) or OL ID_PLF OLidentifier for a pledged (collateral) position from a TP OL ID_(PLT) orOL ID_PLT OL identifier for a pledged (collateral) position to a TP OLID_(P) or OL ID_P OL identifier for a short or future-dated “payable”transfer OL ID_(R) or OL ID_R OL identifier for a short or future-dated“receivable” transfer

Within a permissioned network, there will be shared source code. Part ofthe controls for the code will be to keep it as simple as possible andideally Turing-incomplete. The genome described in detail below is amechanism to define any financial services life-cycle in terms ofgeneric sequential components.

As previously disclosed, the genome represents a set of fourparameter-driven building blocks (i.e., an asset transfer, an assetclassification change, a gain or loss, and a contingent transfer) which,when combined in different series of sequential orders, can create anytransaction life-cycle in the financial services. This means that anycode of scripts can be written for the generic building blocks and alltransactions will be variations on the themes of block-built transactionlogic. Genome-derived transactions can then easily be formed into thestandardized contractual scripts which any set of counterparties canenter into. The genome-derived transactions allow for the known andconsistent recording of transactions on the decentralized ledger. Havingall transaction activity within the network driven by a standard set ofbuilding blocks prevents any fraudulent activity by any unique orexception-based transactions. The standards also allow twocounterparties to agree upon the transaction script to be executedwithin the network beyond the parameters of the particular trade. Eachtransacting party's node will also independently generate complementarycontra-transactions (i.e., a delivery for every reception), whichcreates a control means for validating each transaction pair; raisingthe level difficulty of malfeasance by involving two parties and makingerror spotting and correction easier.

For example: a payment is a single-timing, asset transfer (A). Thenormal trade of any security for cash would be a contingent transfer(T). Financed transactions can involve both single and contingent assettransfers, which will be driven by gains and losses (e.g., margin calls)as well as collateral designation and pledging (e.g., a change of asecondary security's state). Further transactions could be driven by“generated” credit events (e.g., change of borrower and lender states).All these possibilities can be constructed from various combinations ofthe four sequential transactional components. A representative set ofsample life-cycles are listed in Table 4.

TABLE 4 Representative Set of Sample Life-Cycles Representative SummaryTransactional Transaction Components 1 Payment Single transfer of asset(cash) between two A parties 2 Free Delivery Single transfer of asset(securities) between two A parties 3 FX & FX Forward Reciprocal transferof two assets (currencies) T between two parties 4 FX Roll (Swap)Parties engage in swap: Reciprocal transfer of T two assets (currencies)between two parties, which can be rolled at the choice of the twoparties Reverse, future-dated, reciprocal transfer of two T assets(currencies) between two parties Value gain/loss between two assets(currencies) G Single transfer (FX forward gain/loss) of asset A (cash)between two parties 5 Loan (Cash) - Balloon Loan Issued: Single transferof asset (cash) A Payment between two parties. Future-dated -- interestrate-driven -- reverse A multiple single transfers of asset (cash)Future-dated reverse single transfer of asset A (cash) 6 Loan (Cash) -P&I Loan Issued: Single transfer of asset (cash) A Payment between twoparties. Future-dated -- interest rate-driven -- reverse A multiplesingle transfers of asset (cash) 7 Receive versus Reciprocal transfer oftwo assets (securities and T Payment/Delivery cash) between two parties.versus Payment 8 Repo Reciprocal transfer of two assets (securities andT cash) between two parties, which can be rolled at the choice of thetwo parties. Classify cash/securities as collateral C Future-datedreverse transfer of two assets T between two parties If debtor bankruptor credit event trigger C Credit-driven, collateral liquation with otherthird T party If repo settled: Credit-driven principal + excess Asettlement; repo classified as settled 9 Margin Loan (Long) - Singletransfer of asset (cash) between two A Borrower parties as payable Buy:Reciprocal transfer of two assets T (securities and cash) between twoparties. Payable fill as loan A Pledge of securities as collateral AClassification of securities as collateral C Mark-to-market valuation ofcollateral versus G securities Mark-to-market collateral transfer ASingle transfer of asset (cash + interest) from A client to broker

Various processes employed in one embodiment of a distributed ledgersystem for executing financial transactions will now be described indetail.

Genome Script Building Process

FIGS. 1 through 6 are flowcharts identifying steps of a genome scriptbuilding process in accordance with one embodiment. A Turing-incompletecode consists of simple read, write and stacking functionality with onlyconditional flow and no loops. Once a life-cycle has been defined interms of its genome components, the functional steps can be assembled bythe following logical flow (Start is indicated as step 1 in FIG. 1):

Taking the first transactional component (step 2), the type can bedefined (step 3) by its specification, which determines how it ishandled. Then a determination is made whether (or not) the transactionalcomponent will be either a transfer (step 4), a classification change(step 5), a value change (step 6) or a contingent transfer (step 7).Once the transaction type has been determined, the transaction type willbe recorded (step 8). The genome script building process then proceedsto the parameter assignment algorithm depicted in FIG. 2 (see connectionpoint A1 in FIGS. 1 and 2).

Referring to FIG. 2, each transactional component will be associatedwith an asset or assets, so the number (or identifier) and units (ofvalue) must be assigned and a value may be assigned (step 9) to be usedin the “Number, Unit, Value” script 10 (see connection point B1 in FIGS.2 and 3).

Referring to FIG. 3, a determination is made whether the transactionalcomponent involves a single security or not (step 17). If thetransactional component involves a single security, then a number and aunit will be assigned and a value may be assigned (step 18). If adetermination is made in step 17 that the transactional component doesnot involve a single security, then a determination is made whether thetransactional component involves dual securities or not (step 19). Ifthe transactional component involves dual securities, then numbers andunits will be assigned and values may be assigned (step 20). If adetermination is made in step 19 that the transactional component doesnot involve dual securities, then a determination is made whether thetransactional component involves multiple securities or not (step 21).If the transactional component involves multiple securities, thennumbers and units will be assigned and values may be assigned (step 22).The next parameter to be assigned is the timing (see connection point B2in FIGS. 2 and 3).

Referring again to FIG. 2, each transactional component may have atiming-driven event, so the timing may be determined (step 11) to beused in the “Timing” script 12 (see connection point C1 in FIGS. 2 and4). Referring to FIG. 4, a determination is made whether the timingevent is a single event, which will then cause a subsequenttransactional component to occur, or not (step 23). If a determinationis made in step 23 that the timing event is a single event, then theimpact will be defined as a transfer, contingent transfer,classification change or value change (step 24). If a determination ismade in step 23 that the timing event is not a single event, then adetermination is made whether the timing event is periodic or not (step25). If a determination is made in step 25 that the timing event isperiodic, then the impacts will be defined as transfers, contingenttransfers, classification changes or value changes (step 26). If adetermination is made in step 25 that the timing event is not periodic,then a determination is made whether the timing events are multiple,non-periodic events or not (step 27). If a determination is made in step27 that the timing events are multiple, non-periodic events, the impactswill be defined as transfers, contingent transfers, classificationchanges or value changes (step 28). The next parameter assignment may begenerated events (see connection point C2 in FIGS. 2 and 4).

Referring again to FIG. 2, each transactional component may have agenerated event, so the generated event may be determined (step 13) tobe used in the “Generated Event” script 14 (see connection point D1 inFIGS. 2 and 5). Referring to FIG. 5, a determination is made whether theevent is a data-driven event or not (step 29). If a determination ismade in step 29 that the event is a data-driven event, then the triggerevent and action or impact will be recorded against that parameter (step30). After step 30 or if a determination is made in step 29 that theevent is not a data-driven event, then a determination is made whetherthe event is a date-driven event or not (step 31). If a determination ismade in step 31 that the event is a date-driven event, then the triggerevent and action or impact will be recorded against that parameter (step32). After step 32 or if a determination is made in step 31 that theevent is not a date-driven event, then a determination is made whetherthe event is a state-driven event or not (step 33). If a determinationis made in step 33 that the event is a state-driven event, then thetrigger event and action or impact will be recorded against thatparameter (step 34). After step 34 or if a determination is made in step33 that the event is not a state-driven event, then a determination ismade whether the event is a choice-driven event or not (step 35). If adetermination is made in step 35 that the event is a choice-drivenevent, then the trigger event and action or impact will be recordedagainst that parameter (step 36). After step 36 or if a determination ismade in step 35 that the event is not a choice-driven event, then adetermination is made whether the event is a value upper limit event ornot (step 37). If a determination is made in step 37 that the event is avalue upper limit event, then the trigger event and action or impactwill be recorded against that parameter (step 38). After step 38 or if adetermination is made in step 37 that the event is not a value upperlimit event, then a determination is made whether the event is a valuelower limit event or not (step 39). If a determination is made in step39 that the event is a value lower limit event, then the trigger eventand action or impact will be recorded against that parameter (step 40).The next parameter assignment will be the type of asset (e.g., security)impacted (see connection point D2 in FIGS. 2 and 4).

Referring again to FIG. 2, each transactional component action or impactwill affect one of the security types, so the impacted asset may bedetermined (step 15) to be used in the “Asset Impacted” script 16 (seeconnection point E1 in FIGS. 2 and 6). Referring to FIG. 6, eachtransaction component action or impact will affect one of the securitytypes. If the security impacted is the primary security (as determinedin step 41), then the impact will be assigned to that primary security(step 42). If the security impacted is the secondary security (asdetermined in step 43), then the impact will be assigned to that secondsecurity (step 44). If the securities impacted are tertiary securities(as determined in step 45), then the impact will be assigned to thetertiary securities (step 46). The script component will now be fullydefined as far as securities and impact events driven by certaintriggers. The genome script building process then proceeds to step 47seen in FIG. 1 (see connection point A2 in FIGS. 1 and 6). Adetermination is made whether the most recently processed transactionalcomponent is the last transactional component to be processed (step 47).If a determination is made in step 47 that there are more components tothe script, then the next component will be lined up for definition(step 48) and the genome script building process will return to step 3.If a determination is made in step 47 that the most recently processedtransactional component was the last component, then the genome scriptbuilding process will end (step 49).

Genome Script Running Process

FIGS. 7 through 12 are flowcharts identifying steps of a genome scriptrunning process in accordance with one embodiment. The script runninglogic will be executed in the order of its sequential components andfollows a parallel logic to the script building logic. The componentsmay be pending over long periods of time waiting for conditional eventsor triggers to occur, whereupon the correct parameter-driven event orimpact can be executed.

Referring to FIG. 7, the Start of the script running logic is to takethe first transactional component of the life-cycle script (step 50),read the transacting party, transaction and ownership log data (step51), and then determine whether there is a timing event or not (step53). If there is a timing event, then the process proceeds to the timingevent review depicted in FIG. 8 (see connection point G1 in FIGS. 7 and8). If it is determined in step 53 that it is not a timing event, then adetermination is made whether it is a generated event or not (step 55).If it is a generated event, then the process proceeds to the generatedevent review depicted in FIG. 9 (see connection point H1 in FIGS. 7 and9). If it is determined in step 55 that it is not a generated event,then a determination is made whether the most recently processedtransactional component is the last transactional component to beprocessed (step 94). If a determination is made in step 94 that thereare more components to the script, then the next component will be linedup to be read (step 95) and the genome script running process willreturn to step 51. If a determination is made in step 94 that the mostrecently processed transactional component was the last component, thenthe genome script running process will end (step 96).

For a transactional component with a timing event, the process depictedin FIG. 8 is performed. First, a determination is made whether thetiming event is a single event or not (step 56). If a determination ismade in step 56 that the timing event is a single event, then the singletiming event impact is retrieved (step 57 a) and the impact event iscollated (step 57 b). If a determination is made in step 56 that thetiming event is not a single event, then a determination is made whetherthe timing event is periodic or not (step 58). If a determination ismade in step 58 that the timing event is periodic, then the periodictiming event impact is retrieved (step 59 a) and the impact event iscollated (step 59 b). (As used herein, the term “collate” means toassemble the data relevant to the “impact”, which will then be used whenthe transfer, classification change, value change or contingent transferare processed.) If a determination is made in step 58 that the timingevent is not periodic, then a determination is made whether the timingevents are multiple, non-periodic events or not (step 60). If adetermination is made in step 60 that the timing events are multiple,non-periodic events, then the multiple non-periodic timing events'impact is retrieved (step 61 a) and the impact event is collated (step61 b). Whether there is a timing event or not, the genome scriptbuilding process will proceed to the security type review processdepicted in FIG. 10 (see connection point J1 in FIGS. 8 and 10).

For a transactional component with a generated event, the processdepicted in FIG. 9 is performed. First, a determination is made whetherthe event is a data-driven event or not (step 62). If a determination ismade in step 62 that the event is a data-driven event, then the eventtrigger and action data is retrieved (step 63 a) and the impact or eventis collated (step 63 b). If a determination is made in step 62 that theevent is not a data-driven event, then a determination is made whetherthe event is a date-driven event or not (step 64). If a determination ismade in step 64 that the event is a date-driven event, then the eventtrigger and action data is retrieved (step 65 a) and the impact or eventis collated (step 65 b). If a determination is made in step 64 that theevent is not a date-driven event, then a determination is made whetherthe event is a state-driven event or not (step 66). If a determinationis made in step 66 that the event is a state-driven event, then theevent trigger and action data is retrieved (step 67 a) and the impact orevent is collated (step 67 b). If a determination is made in step 66that the event is not a state-driven event, then a determination is madewhether the event is a choice-driven event or not (step 68). If adetermination is made in step 68 that the event is a choice-drivenevent, then the event trigger and action data is retrieved (step 69 a)and the impact or event is collated (step 69 b). If a determination ismade in step 68 that the event is not a choice-driven event, then adetermination is made whether the event is a value upper limit event ornot (step 70). If a determination is made in step 70 that the event is avalue upper limit event, then the event trigger and action data isretrieved (step 71 a) and the impact or event is collated (step 71 b).If a determination is made in step 70 that the event is not a valueupper limit event, then a determination is made whether the event is avalue lower limit event or not (step 72). If a determination is made instep 72 that the event is a value lower limit event, then the eventtrigger and action data is retrieved (step 73 a) and the impact or eventis collated (step 73 b). Except for a choice-driven event (determined instep 68), whether there is a generated event or not, the process willproceed to the security type review process depicted in FIG. 10 (seeconnection point J1 in FIGS. 9 and 10). If there is a choice-drivenevent, the process then executes the script running control algorithmdepicted in FIG. 7 (see connection point N1 in FIGS. 7 and 9).

Referring to FIG. 7, a determination is made whether the choice is toroll the current transaction or not (step 52). If it is determined instep 52 that the choice is not to roll the current transaction script,then the genome script running process, will proceed to the securitytype review process depicted in FIG. 10 (see connection point J1 inFIGS. 7 and 10). If it is determined in step 52 that the choice is toroll the current transaction script, then reset and agree the rolledtransaction script (step 54) and start with the first transactioncomponent again (step 50). (As used herein, the term “roll” means tocontinue an open-ended transaction. A repo is a repurchase agreement,normally agreed for overnight financing. If the counterparties want tocontinue the transaction for another day, they agree to “roll” it. Thetransaction then has a financial settlement that repeats under the nextday's financing rate. This is the mechanism to have an open-endedtransaction without an infinite loop.)

The security type review process is depicted in FIG. 10. First, adetermination is made whether the transactional component involves asingle security or not (step 74). If the transactional componentinvolves a single security, then the security data for the impact orsubsequent event will be retrieved (step 75), after which the genomescript running process will proceed to the impacted security reviewprocess depicted in FIG. 11 (see connection point K1 in FIGS. 10 and11). If a determination is made in step 74 that the transactionalcomponent does not involve a single security, then a determination ismade whether the transactional component involves dual securities or not(step 76). If the transactional component involves dual securities, thenthe securities data for the impact or subsequent event will be retrieved(step 77), after which the genome script running process will proceed tothe impacted security review process depicted in FIG. 11. If adetermination is made in step 76 that the transactional component doesnot involve dual securities, they are multiple securities so thesecurities data for the impact or subsequent event for those multiplesecurities will be retrieved (step 78), after which the genome scriptrunning process will proceed to the impacted security review processdepicted in FIG. 11.

Referring to FIG. 11, a determination is made whether the asset impactedis a primary security or not (step 79). If a determination is made instep 79 that the asset impacted is a primary security, then retrieve theimpact data on the primary security (step 80 a) and create the event orimpact to be processed and recorded (step 80 b). If a determination ismade in step 79 that the asset impacted is not a primary security, thena determination is made whether the asset impacted is a secondarysecurity or not (step 81). If a determination is made in step 81 thatthe asset impacted is a secondary security, then retrieve the impactdata on the secondary security (step 82 a) and create the event orimpact to be processed and recorded (step 82 b). If a determination ismade in step 81 that the asset impacted is not a secondary security,then a determination is made whether the asset impacted is a tertiarysecurity or not (step 83). If a determination is made in step 83 thatthe assets impacted are tertiary securities, then retrieve the impactdata on the tertiary securities (step 84 a) and create the events orimpacts to be processed and recorded (step 84 b). The genome scriptrunning process then proceeds to the event processing algorithm depictedin FIG. 12 (see connector L1 in FIGS. 11 and 12).

Referring to FIG. 12, a determination is made whether (or not) thecomponent 85 will be either a transfer (step 86), a classificationchange (step 88), a value change (step 90) or a contingent transfer(step 92). If a determination is made in step 86 that the transactionalcomponent will be a transfer, then process the transfer (step 87). If adetermination is made in step 88 that the transactional component willbe a classification change, then process the classification change (step89). If a determination is made in step 90 that the transactionalcomponent will be a value change, then process the value change (step91). If the transactional component is none of the three, then adetermination is made that the transactional component will be acontingent transfer (step 92), which contingent transfer is thenprocessed (step 93). After each of steps 87, 89, 91 and 93, the genomescript running process proceeds to the transactional component controlalgorithm depicted in FIG. 7 (see connector F1 in FIGS. 1 and 12).

Referring to FIG. 1, if the previous transactional component and itsprocessed impact or event is not the last transactional component to berun (step 94), then select the next sequential transactional component(step 95) and repeat entire genome script running algorithm. If theprevious transactional component and its processed impact or event isthe last transactional component (step 94), then the genome scriptrunning process can end (step 96).

Note: both the script building and running processes do not involveinfinite loops and lend themselves to be compiled in Turing-incompletecode. All financial services transaction life-cycles can be expressed asdifferent sequences and orders of the four transactional components ofthe Genome. Open-ended transactions or financial contracts can beinvoked by the “choice” event (step 68), where the choice to roll orcontinue (step 52) would invoke a repeat of the script to process (step54) the next sets of transactional components in the order theyprocessed before using the same script running algorithm again (step51).

Ownership Loci Records of Value

The types of data stored on the ownership log (OL) are listed in Table5. This represents the data associated with every ownership position onthe ownership log. With the transaction log references, the history of atransaction can be verified either inter-day (looking at the archivedtransaction logs) or intra-day (reviewing the current period'stransaction and ownership log entries in a chain of ownership back tothe SOP OL).

TABLE 5 Ownership Log Data Ownership Log OL ID Encumbrance Asset IDAmount N_(DEL) ID N_(DEL) FL ID N_(DEL) FL_(Address) N_(REC) ID N_(REC)FL ID N_(REC) FL_(Address) Date Transacted Date to be Posted OL ID =“Long”, P, R, L, B, PLT or PLF Linked OL ID for P, R, L, B, PLT or PLF

The last row in Table 5 is the cross reference to the source position ofvalue or OL ID, from which the loan (L), borrow (B), pledge (P), return(R), pledge to (PLT) or pledge from (PLF) record is derived. This isalso a control for the return of the loan or pledged positions.

The relationship for a TP_Del, the unique OL IDs and the encumbrance canbe represented as follows:

Math transformation f[TP_Del pk,Data (e.g., Nonce)]→OL ID

Math transformation f[TP_Del OL ID,Data (e.g., Nonce)]→Encumbrance

It is expected that transacting parties may choose differentmathematical functions to provide unique OL IDs to reference theirpositions of value and to create each position's encumbrance. Therevealing of the identity and unlocking the encumbrances will work likethe locking scripts used with encumbrances in the bitcoin UXTO and willbe part of the transaction scripts for the transacting parties to use.Upon calling the identity reveal script, the receiving transacting party(TP_Rec) can use the “Reveal Data” to confirm the identity of thecounterparty. Upon calling the encumbrance unlocking script, thedelivering transacting party (TP_Del) can unlock the value to create atransaction.

For TP_Del to confirm its identity to TP_Rec, it will provide ‘RevealData’ such that TP_Rec can combine it with TP_Del's pk and perform thefollowing operation:

If Math transformation f[TP_Del pk,Reveal Data]=OL ID, then

-   -   TP_Del is owner of pk and therefore owns the asset amount of        value Amt referenced by the OL ID.

When TP_Del creates the transaction, the unlocking script will performthe following operation:

If Math transformation f[TP OL ID,Unlock Data]=Encumbrance,

-   -   then allow Tx to be created versus OL ID.

Ownership Transfer Logic Summary

FIG. 13 is a diagram identifying transfer entries in an ownership log(stored in a non-transitory tangible computer-readable storage medium)in accordance with one embodiment. FIG. 13 employs the followingterminology: TP_(DEL) is the delivering transacting party; TP_(REC) isthe receiving transacting party; Amt_(St) is the starting balance of thedelivering transacting party; Amt_(T) is the transferred amount; andNet=Amt_(St)−Amt_(T).

A transfer involves the transfer of value from TP_(DEL) to TP_(REC). Thetransfer will be recorded on the ownership log under three unique IDs:OL ID 1 versus the amount of value held by TP_Del; OL ID 2 versus theamount transferred to TP_Rec; and OL ID 3 for the net amount, if any,retained by TP_Del.

FIG. 14 is a diagram identifying contingent transfer entries on theownership log. FIG. 14 employs the following terminology: TP1_(DEL) isthe transacting party delivering asset A; TP2_(REC) is the transactingparty receiving asset A; TP2_(DEL) is the transacting party deliveringasset B; TP1_(REC) is the transacting party receiving asset BA; OL ID 1Ais the identifier for the starting balance for asset A; OL ID 2A is theidentifier for asset A transferred; OL ID 3A is the identifier for netasset A retained by TP1_(DEL); OL ID 1B is the identifier for thestarting balance for asset B; OL ID 2B is the identifier for asset Btransferred; OL ID 3B is the identifier for net asset B retained byTP2_(DEL); Amt_(StA) is the starting asset A balance of TP1_(DEL);Amt_(TA) is the amount of asset A transferred by TP1_(DEL);NetA=Amt_(StA)−Amt_(TA), Amt_(StB) is the starting asset B balance ofTP2_(DEL); Amt_(TB) is the amount of asset B transferred by TP2_(DEL);and NetB=Amt_(StB)−Amt_(TB).

A contingent transfer is a bilateral, dual transfer of two assetssimultaneously. Examples include: receipt versus payment (RVP), deliveryversus payment (DVP), FX transactions (two currencies), and collateralsubstitutions that can be asset-to-cash or asset-to-asset transfers. Thedual transfers will be recorded on the ownership log under two sets ofthree unique IDs: OL ID 1 versus the amount of value held by TP_Del; OLID 2 versus the amount transferred to TP_Rec; and OL ID 3 for the netamount, if any, retained by TP_Del. For each transfer there are twoassets: asset A and asset B, which have their own respective OL IDs andtransfer amounts. With respect to asset agnostic reflection, thecontingent transfers are complementary receipt versus delivery (RVD) anddelivery versus receipt (DVR).

With respect to block trades by brokers on behalf of multi-partysettlements for fund managers representing multiple beneficial ownersunder the same strategy, the transacting script would be pre-allocatedcontingent transactions to each of the underlying beneficial owners'ledgers. They would be processed as “short” contingent transfers (seeFIG. 27) with an unspecified monetary amount. The broker is then free toexecute trades in the markets (fills) and through aggregation create theownership log positions and IDs to reference to fill the shorts with theexecution price of the trade for the fund manager.

FIG. 15 is a diagram identifying pledge and pledge return entries on theownership log. FIG. 15 employs the following terminology: TP_(PLF) isthe transacting party the pledge is from; TP_(PLT) is the transactingparty the pledge is to; OL ID_PLF is the identifier for the pledge fromTP_(PLF); OL ID_PLT is the identifier for the pledge to TP_(PLT);Amt_(St) is the starting balance of TP_(PLF); Amt_(PL) is the pledgeamount; Net=Amt_(St)−Amt_(PL); Amt_(St2) is the available pledge returnbalance for TP_(PLT); Net₂=Amt_(St2)−Amt_(PL); OL IS 1₂ is theidentifier for the balance for pledge return; OL IS 2₂ is the identifierfor pledge amount Amt_(PL) returned; OL IS 3₂ is the identifier forpledge return Net₂.

A pledge is a different kind of transfer. One transacting party ispledging an amount of an asset to another transacting party. The assetwill be used as collateral and will either be held in escrow oravailable for re-hypothecation. Beyond recording the amount pledged withthe normal transfer OL IDs 1-3, the transaction records unique IDs forthe “pledged from” transfer from TP_PLF and “pledged to” transfer toTP_PLT. Note: TP_PLT may be able to further transfer, pledge or lend theasset pledged to it but a record of the pledge transfer and theobligation to return the asset must be kept on the ownership log.

For a return of a pledged security, the recipient may have hypothecatedor used the pledge position. Therefore the position or OL ID referencedwill more than likely be new and unique. In FIG. 15, the pledgerecipient referenced position for the pledge return becomes OL ID 1₂.The returned pledge is OL ID 2₂ and the net position retained byreturnee is OL ID 3₂.

FIG. 16 is a diagram identifying loan and loan return entries on theownership log. FIG. 16 employs the following terminology: TP_(L) is thelender; TP_(B) is the borrower; OL ID_B is the identifier for theborrowed amount; OL ID_L is the identifier for the loaned amount;Amt_(St) is the starting balance of TP_(L); Amt_(L) is the loan/borrowamount; Net=Amt_(St)−Amt_(L); Amt_(St2) is the available loan repaymentbalance for TP_(B), Net₂=Amt_(St2)−Amt_(L); OL ID 1₂ is the identifierfor the balance for loan return; OL ID 2₂ is the identifier for loanamount Amt repaid; OL ID 3₂ is the identifier for loan repayment Net₂.

A loan is a transfer with the promise in the future to return theamount. Beyond recording the amount loaned with the normal transfer OLIDs 1-3, the transaction records unique IDs for the “loan” transfer fromTP_L and “borrow” transfer to TP_B. Note: The borrower TP_B is free touse the asset in many different ways and may further transfer, loan orpledge the amount received. However, a record of the loan and theobligation to repay it must be kept on the ownership log.

For a return of a loaned security, the borrower will have used theborrowed position. Therefore, the position or OL ID referenced for therepayment of the loan will more than likely be new and unique. In FIG.16, the borrower's referenced position for the loan return or repaymentbecomes OL ID 1₂. The paid-off loan is OL ID 2₂ and the net positionretained by the borrower is OL ID 3₂.

FIG. 17A is a diagram identifying ownership log entries for Airlocktransfer into the network. FIG. 17A employs the following terminology:TP_(REC) is the receiving transacting party; AL_(DEL) is the Airlocktransaction log that receives the transaction information from outsidethe network; OL ID D is the external delivering third party; and Amt_(T)is the transferred amount.

FIG. 17B is a diagram identifying ownership log entries for Airlocktransfer out of the network. FIG. 17B employs the following terminology:TP_(DEL) is the delivering transacting party; AL_(REC) is the Airlocktransaction log that receives the transaction information from thenetwork; OL ID E is the external receiving third party; Amt_(St) is thestarting balance of the delivering transacting party; Amt_(T) is thetransferred amount; and Net=Amt_(St)−Amt_(T).

For transfers of value into and out of the network, a separate ledgerwill be maintained called the “Airlock”. Although ownership does notchange in the transaction, it provides a means for the network tocontrol transfers of value in and out through a single process. Oneshared service in the network will be the independent settlement andreconciliation of the transfers into and out of the network.

Initially, this functionality will be used to allow the networkparticipants to transact with non-participants whose transactions stillsettle under current market practices while adoption of the utility isin progress. It can also be used to transfer value between differentimplementations of the network, which may exist in independent forms forcertain products, markets or regions.

Transaction and Ownership Log Posting Logic

A. Fractal Lattice Address Sequencing and Hash-Linking Logic

The proposed distributed ledger system for financial services disclosedherein comprises a fractal lattice-structured transaction log thatutilizes fractal lattice address sequencing and hash-linking logic. FIG.18 is a diagram showing a fractal lattice self-defining andself-verifying process for simple fractal lattices (having a fractalnumber Fn=2) respectively constructed at two nodes N_(DEL) and N_(REC)that create the delivery and receipt contra-transactions for a transfer.

As seen in FIG. 18, the use of a fractal lattice represents a variablen-dimensional structure of geometrically expanding, interconnecting butnon-recurring points that form respective fractal lattice-structuredtransaction logs 99 and 100 in nodes N_(DEL) and N_(REC) respectively.Each point can be given a unique, non-recurring number or address(FL_Address) (e.g., 1a to 1111a and 1b to 1111b as seen in FIG. 18).Each FL_Address is a calculable, algorithmic means to organize, link andreference data within a database. The relationship of all the fractallattice addresses is such that the communication of the individualfractal lattice addresses, in any order, allows a second party toreconstruct the fractal lattice without the need to refer back to theparty who communicated the components. By hash-linking the linkedfractal lattice addresses to a previously utilized address (e.g., parentFL_Address to child FL_Address) in sequential layers with the associateddata (indicated by rectangles labeled “Tx”) referenced to the fractallattice address also allows the second party to confirm the integrity ofthe data within the child FL_Address (“Hash-Link #”). The firsttransaction at FL_Address 1a from the current transacting period fornode N_Del (101) will be hash-linked to the last transaction from theprior period's fractal lattice-structured transaction log 97 (N_(DEL)EOP FL). Similarly, the first transaction at FL_Address 1b from thecurrent transacting period for node N_Rec will be hash-linked to thelast transaction from the prior period's fractal lattice-structuredtransaction log 98 (N_(REC) EOP FL).

For the simplest example, within the fractal lattice contra-transactionsTx_Del (122) and Tx_Rec (132) (indicated by respective rectangles inFIG. 18) will be assigned and posted to sequential fractal latticeaddresses 111a and 1011b in the order in which the nodes N_(DEL) andN_(REC) create the contra-transactions.

The examples seen in FIG. 18 are of simple numerical, self-similarfractal lattice patterns. There are a multitude of more complexgeometrically and complex-number defined fractal patterns. As long asthe fractal pattern for addressing and linking the data is defined, manymore options are available for organizing and securely recording thedata. There is also the possibility of using symmetrical encryption forthe hash-links on the fractal lattice addresses that can bepre-communicated to counterparty nodes. Although this will add a levelof complexity and computing time to the process, it will provide anotherobstacle to prevent or at least delay the opportunity for malfeasance.

Referring again to FIG. 18, contra-transaction 122 at FL_Address 111aand contra-transaction 132 at FL_Address 1011b will be hash-linked to aparent FL_Address in the prior layer of the fractal lattice (i.e., 11aand 101b). The algorithm for defining the sequential fractal latticeaddresses and calculating the parent FL_Address for hash-linking, forthe illustrated example, is defined below. [Note: There is norequirement to fill the fractal lattice addresses sequentially or tofill all the fractal lattice addresses. For example, within fractallattice-structured transaction log 99, addresses 1000a to 1111arepresent unused addresses in the pattern at this time. Within fractallattice-structured transaction log 100, addresses 1100b to 1111b(excluding address 1011b) represent unused addresses in the pattern atthis time. There is no information posted at those addresses. Incontrast, addresses 1a, 10a, 11a, 100a, 101a and 110a representtransactions prior to the example transaction that have already beenposted to the fractal lattice, so their details are irrelevant for thediscussion. The fact that they exist and have been posted highlightsused and now unavailable FL addresses. The transactions posted toaddresses 1a, 10a, 11a, 100a, 101a and 110a also representcontra-transactions which may match to contra-transactions in othernodes.]

The different branches of the fractal lattice could be utilized tosegregate or organize transaction data for later ease of reference orshorter data inquiry requirements. As long as the initial layertransactions are hash-linked to the prior period's last transaction, thefractal lattice can be started at the layer with enough addresses tosegregate the data to preference. The number of addresses in the initiallayer will determine the possible fractal numbers for the pattern asFn^(x) will be greater than or equal to the number of addresses in theinitial layer. If there are 63 transaction data groups, a fractallattice with a layer of 64 addresses could be used. The subsequentfractal numbers for the next layers and fractal lattice addresses couldbe 2, 4 or 8 as 2⁶, 4³ and 8²=64.

If for any fractal lattice of fractal number Fn:

L_x=layer number which ranges from x=1 to x=X

L_Xa=the number of addresses in any one layer=Fn ^((L) ^(_) ^(x−1))

d=FL_Address digit where d's value range is: 1≤d≤Fn−1

Then for any layer L_x:

-   -   FL_Address will be defined as a number where the number of        sequential digits=d₁ d₂ d₃ . . . d_(L) _(_) _(Xa)    -   The fractal lattice addresses will run sequentially, in        numerical order, within a range:    -   FL_Address of d₁=1 and the digits d₂ to d_(L) _(_) _(Xa)=0    -   to    -   FL_Address of d₁=1 and the range of digits d₂ to d_(L) _(_)        _(Xa)=Fn−1    -   In base (Fn): each address in each layer will be numbered        sequentially from:

(Fn ^((L) ^(_) ^(x−1)) to [Fn ^((L) ^(_) ^(x−1))+(Fn ^((L) ^(_)^(x−1))−1)]

-   -   The parent FL_Address for an FL_Address=d₁ d₂ d₃ . . . d_(L)        _(_) _(Xa) is the same FL_Address without the last digit:    -   i.e., child FL_Address=d₁ d₂ d₃ . . . d_((L) _(_) _(Xa−1))        [Note: the number of child FL_Addresses hash-linked to a parent        FL_Address=Fn. The randomizing of the types of hash-links (e.g.,        parents, grandparents, uncle/aunt, cousin, siblings, etc.) or        multiple linkages can provide unstructured yet re-creatable data        links, as they will be referenced in the transaction (see FIG.        18).]

A fractal lattice self-defining and self-validating process inaccordance with one embodiment will now be described with reference toFIG. 18. Referring to FIG. 18, as contra-transactions 122 and 132 arecommunicated to the network and, beyond the other control and validationtechniques, the fractal lattice structure of the transaction databasecreates a means to both define structure, position and contentintegrity, without the need to refer to the originating node or othernodes for confirmation.

(a) Each contra-transaction 122 and 132, as it is created by arespective node (i.e., N_(DEL) or N_(REC)), is assigned a respectivesequential fractal lattice address (e.g., 111a and 1011b in FIG. 18).

(b) The transaction content is hash-linked to the prior layer's parentor other relation's FL_Address linked-hash (e.g., FL_Address 11 a viahash-link 395 and FL_Address 101b via hash-link 396 in FIG. 18). [Note:A simple parent-child hash-link is described. For more uncertainty tothwart malfeasance, the originating node could vary hash-links to say“grandparent” (1a and 10b) or “sequential” (110a and 1010b) or“sequential-2” (101a and 1001b) or use multiple links, as long as thatlink methodology is communicated in the transaction data (see FIG. 18).

(c) Every node will identify its last transaction of a period, Tx_Last(e.g., transaction 132 at FL_Address 1011b in FIG. 18), for other nodesto know when the fractal lattice is complete or use an empty (null)address to signal Tx_End (e.g., at FL_Address 101a in FIG. 18).

The combination of the foregoing elements (a) through (c) allows anynode in the network to update its copy of the transaction originatingnodes' fractal lattices (i.e., 99 and 100 in FIG. 18). It will post thetransaction to the assigned FL_Address (e.g., 111a and 1011b) and beable to verify the expanding structure and transaction content byvalidating the hash-links (e.g., 395 and 396) without having to conferwith the originating nodes' transaction records (99 or 100) or any othernode.

As seen in FIG. 18, (1) N_(DEL) transacts with N_(REC); (2) N_(DEL)records the transaction on its fractal lattice-structured transactionlog 99 on the next available FL_Address=111a, hash-links (395) it to theparent FL_Address=11a and broadcasts it to the network; (3) N_(REC)records the transaction on its fractal lattice-structured transactionlog 100 on the next available FL_Address=1011b, hash-links (396) it tothe parent FL_Address=101b and broadcasts it to the network; and (4) theFL_Addresses 111a and 1011b in the respective contra-transactions 122and 132 allow any node to replicate the structure of the fractal latticeand the hash-link allows the receiving node to match and confirmintegrity regardless of the order of receipt of the transactions (seeFIG. 18). [Note: Both the fractal lattice addresses and the relationshipof parent to child fractal lattice addresses are algorithmicallycalculable.] The whole fractal lattice structure can have its entirepopulation of hash-linked addresses re-verified at any time during andat the end of a transacting period.

For the simple numerically derived fractal lattices, Fn=1 creates aclassic, one-dimensional blockchain, whereby the next block has only oneplace where it can be placed.

B. Digital Signature and Encrypted Hash (E#)

For each node, the digital signature (Sig) is an sk encryption of ahashed message. The message that is hashed for a transaction is all thefields listed in the “Tx Details” section below. The standard practiceis to send:

Sig=sign(Message,sk).

The recipient then performs:

isValid=verify(pk,message,Sig)

If isValid is true, then the message was not tampered with.

Because encryption needs a lot of computing power but hashing does not,the standard practice: Sig=sign(Message, sk) actually means send the“message” and send a hash of the message (encrypted with the sender'sprivate or secret key—sk) with it (a hash is only a 64-digithexadecimal). At the other end, the recipient makes a hash of the“message” and decrypts the encrypted hash (with the sender's publickey). If the two hashes are the same, then the recipient knows themessage came from and was digitally signed by the sender.

For the encrypted hash E#, because it is using standard fields withintransaction script, the sender need only include the encrypted hashbecause the recipient knows which fields in the transaction script tohash to validate the decrypted E#.

FIGS. 19A and 19B are diagrams showing the process for digitally signingand verifying delivery and receipt contra-transactions. In FIG. 19A, thesignature sender is a node N_(DEL) that is generating a deliverycontra-transaction for a transaction and the signature receiver is anode N_(REC) that is generating a receipt contra-transaction for thesame transaction. Conversely, in FIG. 19B, the signature sender is nodeN_(REC) and the signature receiver is node N_(DEL). The respectivedigital signatures are exchanged to ensure secure communications betweenthe two nodes.

Referring to FIG. 19A, block 134 a represents a deliverycontra-transaction Tx_Del generated by node N_(DEL). The transactiondetails are represented by data stored in specific fields of atransaction log maintained by node N_(DEL) (see fields listed in Table6). These fields include an encryption hash N_(REC) E# and dataidentifying the fields used to generate that encryption hash. Tx_Del ishashed using hash process 135 and then the hashed message 136 a isencrypted by an encryption process 137 a that uses the privateencryption key (sk) of node N_(DEL). The resulting digital signature 138a (see N_(DEL) Digital Signature, Field 30 in Table 6) is received bynode N_(REC), where it is decrypted by a decryption process 139 a thatuses the public encryption key (pk) of node N_(DEL). The result of thedecryption process 139 a is a hashed message 140 a for Tx_Del. Inaddition to the hashed message, node N_(DEL) also sends a copy 141 a ofthe delivery contra-transaction details to node N_(REC). Thosetransaction details are hashed by node N_(REC) using a hash process 142to produce hashed message 143 a, which hashed message 143 a is thencompared to hashed message 140 a produced by the decryption process 139a. If the hashed messages match (step 144), then N_(DEL) DigitalSignature is good.

Referring to FIG. 19B, block 134 b represents a receiptcontra-transaction Tx_Rec generated by node N_(REC). The transactiondetails are represented by data stored in specific fields of atransaction log maintained by node N_(REC) (see fields listed in Table7). These fields include an encryption hash N_(DEL) E# and dataidentifying the fields used to generate that encryption hash. Tx_Rec ishashed using hash process 135 and then the hashed message 136 b isencrypted by encryption process 137 b that uses the private encryptionkey (sk) of node N_(REC). The resulting digital signature 138 b (seeN_(REC) Digital Signature, Field 30 in Table 7) is received by nodeN_(DEL), where it is decrypted by a decryption process 139 b that usesthe public encryption key (pk) of node N_(REC). The result of thedecryption process 139 b is a hashed message 140 b for Tx_Rec. Inaddition to the hashed message, node N_(REC) also sends a copy 141 b ofthe receipt contra-transaction details to node N_(DEL). Thosetransaction details are hashed by node N_(DEL) using a hash process 142to produce hashed message 143 b, which hashed message 143 b is thencompared to hashed message 140 b. If the hashed messages match (step144), then N_(REC) Digital Signature is good.

If after the data sharing process, the digital signatures have beenverified, then the delivery contra-transaction data is posted by nodesN_(DEL) and N_(REC) to respective delivery transaction logs and thereceipt contra-transaction data is posted by nodes N_(DEL) and N_(REC)to respective receipt transaction logs. In addition, node N_(DEL)broadcasts Tx_Del (which includes N_(REC) E#) to the network and nodeN_(REC) broadcasts Tx_Rec (which includes N_(DEL) E#) to the network,which information can be received by an independent node N_Ind (notshown in FIGS. 19A and 19B).

B.1. Multi-Signature Encrypted Hash (E#).

FIG. 20 is a flowchart showing a process for recording transactions onan independent node using multi-signature encrypted hashing inaccordance with one embodiment. The encrypted hash E# is used as a formof multi-signature control and contra-transaction matching and linking.

Referring to FIG. 20:

N_Del creates N_Del E# by hashing {N_(DEL) sk(Message=N_(DEL) ID,N_(DEL) FL_(Address), N_(REC) ID, Asset ID, Amount)} (step 156) and thenencrypting that hashed message using its own private encryption key sk(step 157).

N_Del shares N_Del E# data with N_Rec (step 158).

N_Rec creates N_Rec E# by hashing {N_(REC) sk(Message=N_(REC) ID,N_(REC) FL_(Address), N_(DEL) ID, Asset ID, Amount)} (step 160) and thenencrypting that hashed message using its own private encryption key sk(step 161).

N_Rec shares N_Rec E# data with N_Del (step 162).

N_Del Tx_Del 163 does not identify N_Rec but has the N_Rec E# withoutidentifying that N_Rec produced it.

N_Rec Tx_Rec 159 does not identify N_Del but has the N_Del E# withoutidentifying that N_Del produced it.

When the two contra-transactions 164 and 165 are matched (indicated by atwo-headed dashed arrow in FIG. 20) by the independent node N_Ind, thecontra-nodes N_Del and N_Rec are identified and the encrypted hashes(E#) can be checked and verified. More specifically, N_Rec ID is one ofthe fields, so when the transaction is received by N_Ind or any othernode, it can recreate the hashed message 170 using hash process 166 fromthe consistent N_(REC) Tx E# data fields, including N_Rec ID. The hashedmessage 171 resulting from decryption process 167 (using N_(REC)'spublic encryption key pk) of the N_(REC) Tx E# data fields received inthe matched transaction 164 can then be matched (by matching process391) with the check hashed message 170 to verify the deliverycontra-transaction. In parallel, N_Del ID is one of the fields, so whenthe transaction is received by N_Ind or any other node, it can recreatethe hashed message 173 using hash process 169 from the consistentN_(DEL) Tx E# data fields, including N_Del ID. The hashed message 172resulting from decryption process 168 (using N_(DEL)'s public encryptionkey pk) of the N_(DEL) Tx E# data fields received in the matchedtransaction 165 can then be matched (by matching process 392) with thecheck hashed message 173 to verify the receipt contra-transaction. Thisoffers additional control on transaction broadcasting. To interfere withany transaction, a malfeasant would have to know the identities of bothnodes and their respective private encryption keys. Contra-transactionscan only be matched with the correct nodes; otherwise the encryptedhashes will not match the check hashed messages. As well as digitallysigning the transaction to authenticate its origin, the node has tovalidate an encrypted hash, which includes the ID for both originatingnodes.

Until both transactions are broadcast to the network (unless the partiesor their public encryption keys are known), it is impossible to knowwhich two nodes created the transactions and therefore recreate thepublic encryption key by node ID. The inclusion of transaction detailsprevents fraudulent interference once the transactions are broadcast asany interference would cause a mismatch with the encrypted hashedmessage matching processes 391 and 392 in FIG. 20.

The presence and validation of the encrypted hashes E# also preventsdifferent transactions with identical transaction amounts beingincorrectly matched as the encrypted hashes E# cannot be confirmed basedon one or more of its field components being different.

Without the matching contra-transaction, the encrypted hashed messagecannot be decrypted to be validated. One contra-transaction cannot behijacked and re-used erroneously or as a malfeasant as decrypting andmatching the encrypted hashed message requires the public encryption keyof the unidentified node of the other contra-transaction.

B.2. Digital Signature and E# Summary.

Digital Signatures:

For the delivery contra-transaction, the digital signature is:Sig=sign(Message, sk)=sign (Tx_(DEL), sk[N_(DEL)]).

For the receipt contra-transaction, the digital signature is:Sig=sign(Message, sk)=sign (Tx_(REC), sk[N_(REC)]).

Encrypted Hashes:

For the delivery contra-transaction, the encrypted hash is N_(REC) E#:Sig=sign(Message, sk)=sign (subset[Tx_(DEL), Tx_(REC)], sk[N_(REC)]),where subset [Tx_(DEL), Tx_(REC)]=Hash [N_(REC) ID, N_(REC)FL_(Address), N_(DEL) ID, Asset ID, Amt].

For the receipt contra-transaction, the encrypted hash is N_(DEL) E#:Sig=sign(Message, sk)=sign (subset[Tx_(DEL), Tx_(REC)], sk[N_(DEL)]),where subset [Tx_(DEL), Tx_(REC)]=Hash [N_(DEL) ID, N_(DEL)FL_(Address), N_(REC) ID, Asset ID, Amt].

B.3. Transfer Transaction Details.

FIG. 21 is a schematic illustrating the high-level components of theexecution and recording of a simple transfer process between two nodesN1 _(DEL) and N2 _(REC) connected by a network in accordance with oneembodiment. The contra-transactions 174 and 183 are assigned and postedto the originating node's fractal lattice in the FL_(Address) order andhash-linked to the fractal lattice addresses in transaction logs 180 aand 184 a respectively, which are structurally in the prior layer of therespective fractal lattice structure. The transaction details posted totransaction log 180 a for the delivery contra-transaction are listed inTable 6.

TABLE 6 Tx_(DEL): Transaction Details Posted to N_(DEL) TransactionLog 1. N_(DEL) ID 2. Asset ID 3. Short Fill Status Fill (Y/N) * 4. ShortStatus (Y/N) ⁽²⁾ 5. OL ID 2 Specified Amount (Y/N) * 6. TP_(DEL) OL ID 17. OL ID 1 = “Long”, L, B, PLT or PLF 8. Linked OL ID for OL ID 1 if L,B, PLT or PLF 9. OL ID 1 Amount 10. Tx_(DEL) Amount (OL ID 2) 11.TP_(REC) Tx_(REC) OL ID 2 * 12. OL ID 2 = “Long”, L, B, PLT or PLF * 13.Linked OL ID for OL ID 2 if L, B, PLT or PLF * 14. Contingent Tx Status(Y/N) 15. Contingent Tx FL Address 16. OL ID 2 TP_(REC) Encumbrance *17. If OL ID 2 = Short Fill, then N_(REC) FL ID * 18. If OL ID 2 = ShortFill, then N_(REC) FL_(Address)* 19. Tx_(DEL) Net Amount (OL ID 3) 20.TP_(DEL) TX_(DEL) OL ID 3 21. OL ID 3 = “Long”, L, B, PLT or PLF 22.Linked OL ID for OL ID 3 if L, B, PLT or PLF 23. OL ID 3 TP_(DEL)Encumbrance 24. N_(DEL) FL ID 25. N_(DEL) FL_(Address) 26. N_(DEL)FL_(Address) #_(LINK) 27. N_(DEL) FL_(Address) #_(LINK) Relationship 28.N_(REC) Encrypted # * 29. Tx_(DEL) # 30. N_(DEL) Digital Signature 31.Tx Last (Y/N)The transaction details posted to transaction log 184 a for the deliverycontra-transaction are listed in Table 7 (see below). [Note: Theasterisks in Table 6 indicate data fields which N_(DEL) receives, withinscripting code, from N_(REC); the asterisks in Table 7 indicate datafields which N_(REC) receives, within scripting code, from N_(DEL).] Theassigned address and hash link are included in the transaction detailsthat are transmitted to the network. [Note: Tx_(DEL) does not identifyN_(REC) and Tx_(REC) does not identify N_(DEL). Both are only linkedupon matching the contra-transactions and having their relationshipconfirmed by the encrypted hashes.] This allows any recipient torecreate the identical fractal lattice structure and validate thetransaction content and linkages without having to refer back to theoriginating node or any other node for confirmation.

TABLE 7 Tx_(REC): Transaction Details Posted to N_(REC) Transaction Log   1. N_(REC) ID  2. Asset ID  3. Short Fill Status Fill (Y/N)  4. ShortStatus (Y/N)  5. OL ID 2 Specified Amount (Y/N)  6. TP_(DEL) OL ID 1 * 7. OL ID 1 = “Long”, L, B, PLT or PLF *  8. Linked OL ID for OL ID ifL, B, PLT or PLF *  9. OL ID 1 Amount * 10. Tx_(REC) Amount (OL ID 2)11. TP_(REC) Tx_(REC) OL ID2 12. OL ID 2 = “Long”, L, B, PLT or PLF 13.Linked OL ID for OL ID 2 if L, B, PLT or PLF 14. Contingent Tx Status(Y/N) 15. Contingent Tx FL Address 16. OL ID 2 TP_(REC) Encumbrance 17.If OL ID 2 = Short Fill, then Short N_(REC) FL ID 18. If OL ID 2 = ShortFill, then Short N_(REC) FL_(Address) 19. Tx_(REC) Net Amount (OL ID 3)20. TP_(REC) Tx _(DEL) OL ID 3 * 21. OL ID 3 = “Long”, L, B, PLT orPLF * 22. Linked OL ID for OL ID 3 if L, B, PLT or PLF * 23. OL ID 3TP_(DEL) Encumbrance * 24. N_(REC) FL ID 25. N_(REC) FL_(Address) 26.N_(REC) FL_(Address) #_(LINK) 27. N_(REC) FL_(Address) #_(LINK)Relationship 28. N_(DEL) Encrypted # * 29. Tx_(REC) # 30. N_(REC)Digital Signature 31. Tx Last (Y/N)

C. Transaction Process Flows

C.1. Transfer Process.

The flow depicted in FIG. 21 and the following description illustratethe high-level components of the execution and recording of a simpletransfer (e.g., a payment).

Node 1 (N1 _(DEL)) and Node 2 (N2 _(REC)) for the respective deliveryand receipt transacting parties will each generate the respectivecontra-transactions Tx_(DEL) 174 and Tx_(REC) 183, post them to theirrespective node's fractal lattice-structured transaction logs 180 a and184 a, and broadcast the contra-transactions to the network. Node 1 willcreate, post and broadcast Tx_(DEL) 174 and Node 2 will create, post andbroadcast Tx_(REC) 183. Node 2 can, if the transaction is a longtransaction, confirm the counterparties' ownership on its copy of theownership log 182 as shown by the dot-dash arrow between the ownershiplog 182 and Tx_(REC) 183. The contra-transaction data will be generatedfrom the transaction script, parameters and the data shared between thenodes.

Upon receipt of the counterparty node's transaction, each node willmatch and validate the contra-transaction and post the transaction toits copy of the counterparty node's fractal lattice-structuredtransaction log and update its ownership log. Node 1 will receive N2_(REC) Tx_(REC) 178 from Node 2 via the network, match and validate(process 176 in FIG. 21) it versus N1 _(DEL) Tx_(DEL) 174 and postTx_(REC) 178 to N1 _(DEL)'s copy 184 b of N2 _(REC)'s fractallattice-structured transaction log and then update its copy 175 of theownership log. Node 2 will receive N1 _(DEL) Tx_(DEL) 179 from Node 1via the network, match and validate (process 181 in FIG. 21) it versusN2 _(REC) Tx_(REC) 183 and post Tx_(DEL) 179 to N1 _(REC)'s copy 180 bof N1 _(DEL)'s fractal lattice-structured transaction log and thenupdate its copy 182 of the ownership log.

Reflecting the numbered circles in FIG. 21, the core properties andcontrolled process to record transactions on this distributed ledger areas follows:

(1) The transaction logs and ownership logs are separate.

(2) There is one transaction blockchain per node per security (or groupof securities).

(3) For every transfer, there are two contra-transactions—a deliverycontra-transaction and a receipt contra-transaction.

(4) Each node creates and posts a copy of its contra-transaction to itsown fractal lattice-structured transaction log and broadcasts thecontra-transaction to the network

(5) Each node in the network will receive, match and validate thecontra-transactions and post the resulting transfer to its copy of thecontra-transaction node's fractal lattice-structured transaction log andupdate the ownership log.

C.2. Self-Validating Distributed Ledger Network Process.

With respect to the above transfer process and FIG. 22 and starting withtwo transacting parties TP_(DEL) 185 and TP_(REC) 193 using a script190, reviewing a broader view of the network expanded from FIG. 21demonstrates how the contra-transactions 174 and 183 are generated bynodes N_(DEL) 202 and N_(REC) 203 and how any independent node (N_(IND))204, not involved with the transaction, can receive bothcontra-transactions 196 and 200, match and validate them (process 198)and post them to and recreate a copy 180 c of N_(DEL)'s fractallattice-structured transaction log and a copy 184 c of N_(REC)'s fractallattice-structured transaction log and update N_(IND)'s copy 201 of theownership log independent of and without having to confer with nodesN_(DEL) 202 and N_(REC) 204 that generated the contra-transactions orany other nodes in the network. This is because of the validationprocesses and controls within the contra-transactions and the use of thefractal lattice addresses and hash-linking within the data structure,which can only be replicated in one, correct way.

C.3. Contingent Transfer Process.

FIG. 23 is a schematic illustrating the high-level components of theexecution and recording of a contingent transfer process between Node 1(also referred to as N1 or N_(DEL)) and Node 2 (also referred to as N2or N_(REC)) connected by a network in accordance with one embodiment.The depicted system comprises independent contingent transfer fractallattice-structured DVP and RVP transaction logs 210 and 212 in Node 1and DVP and RVP transaction logs 217 and 218 in Node 2. The nodes of thetwo transacting parties will create matching DVP (213 and 214) and RVP(219 and 216) contra-transactions (i.e., Tx_(DVP) and Tx_(RVP)) with thedetails for both transfers created from the transaction script data andnode-shared data. Once Node 2 receives a copy 213 of Tx_(DVP) and Node 1receives a copy 216 of Tx_(RVP), these contra-transactions are matchedand validated (processes 398 and 397). The contingentcontra-transactions that Nodes 1 and 2 create can be broadcast to thenetwork as each node has the data to do that, i.e., Node 1 can broadcastall four contra-transactions 206, 208, 220 and 225, whereas Node 2 canbroadcast all four contra-transactions 207, 211, 223 and 224.

The RVP node (Node 2) will create a N_RVP Tx_Rec (207) and a N_DelTx_Del (211) for Asset 1 and a N_DVP Tx_Del (223) and a N_RVP Tx_Rec(224) for Asset 2 and update N_Rec's Tx Log 218 (per transfer process,not shown) and its recreated copy of N_DVP's Tx Log 217 (per transferprocess, not shown) and Node 2's copies 215 and 222 of the ownershiplogs for Assets 1 and 2.

The DVP Node (Node 1) will create a N_DVP Tx_Del (206) and a N_RVPTx_Rec (208) for Asset 2 and a N_RVP Tx_Rec (220) and a N_DVP Tx_Del(225) for Asset 1 and update N_Del's Tx Log 210 (per transfer process,not shown) and its recreated copy of N_RVP's Tx Log 212 (per transferprocess not shown) s and Node 1's copies 209 and 221 of the ownershiplogs for Assets 1 and 2.

Although not shown in FIG. 23, the two pairs of contra-transactiontransfers will then be matched, validated and posted to their respectivefractal lattice-structured transaction logs and the respective ownershiplogs updated as per the transfer process described above.

Note: All four of the transfers required to complete the contingenttransfer are generated and broadcast by both originating (contingenttransfer) nodes so that both legs are known to the network. Independentnodes will match and validate the two contra-contingent transfers andsubsequent two sets of two contra-transfers.

C.4. Short Transfer Process.

FIG. 24 is a schematic illustrating the high-level components of theexecution and recording of a short transfer process between two nodesconnected by a network in accordance with one embodiment. For a shorttransfer, TP_Del's node, N_Del (Node 1), creates and broadcasts theagreed short Tx_Del (i.e., Tx_(DEL Sht) 227) to the network and theTP_Rec's node, N_Rec (Node 2) creates and broadcasts the agreed ShortTx-Rec (i.e., Tx_(REC Sht) 234). All nodes can receive, match andvalidate both short contra-transactions and record them in their copiesof the nodes' respective FL transaction logs. N_Del (Node 1) receivesTx_(REC Sht) 233, matches and validates (process 231) Tx_(REC Sht) 233with Tx_(DEL Sht) 227 and posts Tx_(DEL Sht) 227 to its N1_Del short FLtransaction log 226 and posts Tx_(REC Sht) 233 to its copy 228 ofN_Rec's N1_Rec short FL transaction log. Similarly, N_Rec (Node 2)receives Tx_(DEL Sht) 230, matches and validates (process 232)Tx_(DEL Sht) 230 with Tx_(REC Sht) 234 and posts Tx_(REC Sht) 234 to itsN2_Rec short FL transaction log 235 and posts Tx_(DEL Sht) 230 to itscopy 229 of N_Del's N1_Del short FL transaction log. Each shortcontra-transaction contains the information for the respective Tx_Deland Tx_Rec once the short is filled by a referenced “long” ownership logID.

Short Transfer Fill:

Although not shown in FIG. 24, once the “long” ownership log ID isreferenced from another transaction, then each originating node cangenerate the respective Tx_Del and Tx_Rec transfers per the previouslydescribed transfer flow and broadcast them to the network to have therespective ownership logs and fractal lattice-structured transactionlogs updated.

C.5. Short Contingent Transfer Process.

FIG. 25 is a schematic illustrating the high-level components of theexecution and recording of a short contingent transfer process betweentwo nodes connected by a network in accordance with one embodiment. Fora short contingent transfer, TP_DVP short's (TP_ABBA Short) N_DVP Short(Node 1) creates and broadcasts the agreed Tx_DVP short (237) (Tx_ABBAShort) to the network and the other TP_RVP short's (TP_BAAB Short) N_RVPShort (Node 2) creates and broadcasts the agreed Tx_RVP Short (244)(Tx_BAAB Short) to the network. All nodes can receive, match andvalidate both short contra-transactions and record them in their copiesof the TP nodes' respective FL transaction logs.

N_DVP Short (Node 1) receives Tx_RVP Short (243), and matches andvalidates (240) Tx_RVP Short (243) versus Tx_DVP Short (237) and postsTx_DVP Short (237) to its own copy of N1_DVP Short FL Tx Log (236) andposts Tx_RVP Short (243) to its copy of N2_RVP Short's FL Tx Log (238).

N_RVP Short (Node 2) receives Tx_DVP Short (239), and matches andvalidates (242) Tx_DVP Short (239) versus Tx_RVP Short (244) and postsTx_RVP Short (244) to its own copy of N2_RVP Short FL Tx Log (245) andposts Tx_DVP Short (239) to its copy of N1_DVP Short's FL Tx Log (241).

Each short contingent contra-transaction contains the information forthe respective Tx_Del and Tx_Rec of one asset and the respective Tx_Recand Tx_Del of the other contingent asset in readiness for processing the“fills” of the respective “long” ownership log IDs.

In certain circumstances, e.g., for allocations and fills, there will besituations where one leg of the contingent transfer will be for anunspecified amount. This contingent transfer will still be recorded, butthe final transfer amounts to be recorded will be communicated with the“fill”.

Short Contingent Transfer Fill:

Although not shown in FIG. 25, once both “long” OL ID's are referencedfrom another transaction, then each originating node can generate therespective Tx_Del and Tx_Rec for one asset and the respective Tx_Rec andTx_Del for the other asset and broadcast them to the network to have therespective ownership logs and fractal lattice-structured transactionlogs updated per the transfer flow previously described. Each of the twosets Tx_Del and Tx_Rec will reference the contingent transfer FL_Addressas part of their transaction data.

Validation Process and Transaction Matching Controls

A. Transfer Validation Process and Matching Controls

When a node has received both contra-transactions within a transaction,it is able to run through a series of checks and validations to ensurethat both demonstrate integrity and are linked, which will then allowthe update to the ownership log. The validation requires the matching ofdata of both contra-transactions and the verification of both encryptedhashed messages requires a digital signature verification process withspecifically defined data fields from both contra-transactions. Prior tothe matching and validation of the contra-transactions, somepreventative checks are performed first: (1) Does the OL ID 1 amount inthe Tx_Del exist and match the amount referenced by OL ID 1 on theownership log? (2) Is N_Del the node that owns the asset or received thevalue of the asset during the current transaction period and is the nodereferenced against the ownership log? (3) Is there an uninterrupted anduncorrupted chain of ownership of the asset to be delivered via theintra-day period (IDP) ownership log back to the start of period (SOP)ownership log?

For updates to the ownership log, there are two transaction's: Tx1 andTx2. For the types of transfers available, Tx1 and Tx 2 are as shown inTable 8 follows:

TABLE 8 Types of Transfers Transaction Tx1 Tx2 Transfer Tx_Del Tx_RecPledge Tx_PLF Tx_PLT Loan Tx_L Tx_B Contingent Transfer Tx_ABBA Tx_BAABTransfer 1 for Contingent Tx_Del-AB Tx_Rec-AB Transfer Transfer 2 forContingent Tx_Del-BA Tx_Rec-BA TransferAll transfers could be reflected as future-dated shorts or future-datedpayables and receivables.

The checks and validation processes between a Tx_Del and a Tx_Rec are asshown in Table 9:

TABLE 9 Checks and Validation Processes Tx_(DEL) and Tx_(REC) MatchingData Match Criteria Process 1 Tx_(DEL) & Tx_(REC) Asset ID Tx_(DEL)Field = Tx_(REC) Field = True 2 Tx_(DEL) & Tx_(REC) OL ID 1 Tx_(DEL)Field = Tx_(REC) Field = True 3 Tx_(DEL) & Tx_(REC) OL ID 1 Tx_(DEL)Field = Tx_(REC) Field = True Amount 4 Tx_(DEL) & Tx_(REC) AmountTx_(DEL) Field = Tx_(REC) Field = True (OL ID 2) 5 Tx_(DEL) & Tx_(REC)TP_(REC) Tx_(DEL) Field = Tx_(REC) Field = True Tx_(REC) OL ID 2 6Tx_(DEL) & Tx_(REC) OL ID 2 Tx_(DEL) Field = Tx_(REC) Field = TrueTP_(REC) Encumbrance 7 Tx_(DEL) & Tx_(REC) Tx_(DEL) Tx_(DEL) Field =Tx_(REC) Field = True Net Amount (OL ID 3) 8 Tx_(DEL) & Tx_(REC)TP_(DEL) Tx_(DEL) Field = Tx_(REC) Field = True Tx _(DEL) OL ID 3 9Tx_(DEL) & Tx_(REC) OL ID 3 Tx_(DEL) Field = Tx_(REC) Field = TrueTP_(DEL) Encumbrance 10 Tx_(DEL) N_(DEL) FL ID Tx_(DEL) N_(DEL) FL IDExists = True 11 Tx_(DEL) N_(DEL) FL_(Address) Tx_(DEL) N_(DEL)FL_(Address) is Open = True 12 Tx_(DEL) N_(DEL) FL_(Address) Hash[Tx_(DEL) N_(DEL), prior = True #_(LINK) FL_(Address) #_(Link)] =FL_(Address) #_(LINK) 13 Tx_(REC) N_(REC) FL ID Tx_(REC) N_(REC) FL IDExist = True 14 Tx_(REC) N_(REC) FL_(Address) Tx_(REC) N_(REC)FL_(Address) is Open = True 15 Tx_(REC) N_(REC) FL_(Address) Hash[Tx_(REC) N_(REC), Prior = True #_(LINK) FL_(Address) #_(Link)] =FL_(Address) #_(LINK) 16 Tx_(DEL) # Hash [Tx_(DEL)] = Tx_(DEL) # = True17 Tx_(REC) # Hash [Tx_(REC)] = Tx_(REC) # = True 18 N_(DEL) DigitalSignature isValid = verify(N_(DEL) pk, Tx_(DEL) = True #, N_(DEL) sig)19 N_(REC) E# isValid = verify(N_(REC) pk, Tx_(REC) = True subset[Tx_(DEL), Tx_(REC)], N_(REC) E#) 20 N_(REC) Digital Signature isValid =verify(N_(REC) pk, Tx_(REC) = True #, N_(REC) sig) 21 N_(DEL) E# isValid= verify(N_(DEL) pk, Tx_(DEL) = True subset [Tx_(DEL), Tx_(REC)],N_(DEL) E#) Note: A contingent transfer would consist of two sets oftransfers to be validated: a delivery/receipt of one security versus areceipt/delivery of the other security.

B. Ownership Log Update

The unique IDs for recording positions of ownership or value held willfollow a consistent format. However, for the purpose of illustration,they can be generalized into record types. When two contra-transactionsare matched, the updates to the ownership log fall into three primaryrecords: (1) the originating value for the transfer from delivererreferenced (i.e., identified) by OL ID 1; (2) the value transferred tothe recipient referenced by OL ID 2; and (3) the non-zero, net valueretained by the deliverer referenced by OL ID 3. For other transactions:loans and borrows are referenced by OL ID_L and OL ID_B respectively;and pledges from and pledges to are referenced as OL ID_PLF and OLID_PLT respectively. The data fields in each ownership log, inaccordance with one embodiment, are as shown in Table 10:

TABLE 10 Ownership Log Data Fields Ownership Logs TP_(DEL) OL ID 1TP_(REC) OL ID 2 TP_(DEL) OL ID 3 TP_(DEL) OL ID 1 TP_(REC) OL ID 2TP_(DEL) OL ID 3 Encumbrance = Nil Encumbrance Encumbrance TP_(DEL) OLID 1 Asset ID TP_(REC) OL ID 2 Asset ID TP_(DEL) OL ID 3 Asset IDTP_(DEL) OL ID 1 Amount = TP_(REC) OL ID 2 Amount TP_(DEL) OL ID 3 NilAmount N_(DEL) ID N_(DEL) ID N_(DEL) ID N_(DEL) FL ID N_(DEL) FL IDN_(DEL) FL ID N_(DEL) FL_(Address) N_(DEL) FL_(Address) N_(DEL)FL_(Address) N_(REC) ID N_(REC) ID N_(REC) ID N_(REC) FL ID N_(REC) FLID N_(REC) FL ID N_(REC) FL_(Address) N_(REC) FL_(Address) N_(REC)FL_(Address) Date Transacted Date Transacted Date Transacted Date to bePosted Date to be Posted Date to be Posted OL ID = “Long”, P, R, L, OLID = “Long”, P, R, L, OL ID = “Long”, P, B, PLT or PLF B, PLT or PLF R,L, B, PLT or PLF Linked OL ID for P, R, Linked OL ID for P, R, Linked OLID for P, L, B, PLT or PLF L, B, PLT or PLF R, L, B, PLT or PLF

Although the logic shows OL ID 1 being transferred and reflected as OLID 2 and 3, OL ID 2 and 3 effectively become OL ID 1's for the nexttransaction. Although it is not shown here, the implementation of thesystem would preferably involve the capability to reference multiple OLID 1's to allow a larger transfer of value as well. Also, there will bea transfer from/to the same transacting party to allow eitheraggregation or breaking down of position lot sizes.

Transacting Period to Period Controls

A. Intra-Period Linkages

FIG. 26 is a schematic showing an intra-day ownership validation processperformed by an independent node in accordance with one embodiment. Akey principle of the transaction recording logic depicted in FIG. 26 isthat throughout a transacting period, as long as an independent node(N_(IND)), i.e., a node not involved with the broadcast transactions,can reference the SOP ownership log (OL) (246) or IDP ownership log(250, 254, or 257) to validate the correct amounts available fortransfer, then N_(IND) can post the transactions to its copies of theownership log (250, 254 or 257) and the fractal lattice-structuredtransaction logs of the respective originating nodes—N_(REC) 1 throughN_(REC) n (i.e., nodes 247, 248, 249 or 251, 252, 253 or 255, 256, 258).

With the fractal lattice data structure (previously described withreference to FIG. 18) providing confidence in the transactions receivedand the tracking of all transacting nodes, at any point in time a nodecan, not only reference the latest asset position which a node holds,but also trace a chain of ownership back to the SOP ownership log.

For N_(REC) 1 to receive a position not transacted during the currenttransacting period, N_(IND) can validate that the position referenced isrecorded in the SOP ownership log 246 before posting the transaction toits copies of the fractal lattice-structured transaction log 247 and IDPownership log 250.

For N_(REC) 2 to receive a position not transacted during the currenttransacting period, N_(IND) can validate that the position referenced isrecorded in the IDP ownership log 250 before posting the transaction toits copies of the fractal lattice-structured transaction log 252 and IDPownership log 254.

For N_(REC) n to receive a position not transacted during the currenttransacting period, N_(IND) can validate that the position referenced isrecorded in the IDP ownership log 254 before posting the transaction toits copies of the fractal lattice-structured transaction log 258 and IDPownership log 257.

Note: The requirement for any receiving transacting party to accept a“long” transfer from a delivering transacting party is that N_(REC) canconfirm the delivering transacting party's position from its ownrecords.

B. EOP Ownership Validation and Archiving

FIG. 27 is a schematic showing an inter-day ownership validation processperformed by a node in accordance with one embodiment. For each node totransact in a particular asset, it must maintain its own copy of theownership log for that asset, its own fractal lattice-structuredtransaction log for its contra-transactions in the asset and the fractallattice-structured transaction logs for all the participating nodes.

For the ownership log (OL) it will hash link the EOP OL 260 from theprior period to the SOP OL 264 of the next period, which in turn will behash linked to the EOP OL 265 of that period and so on. For an EOP OL,the linking hash will be a Merkel tree hash of all the non-zero entriesfor the following data elements: Unique OL ID, Asset ID, Amount.

For every fractal lattice-structured transaction log (FL) 261-263, thelast transaction of the EOP FL will be hash linked to the firsttransaction of the next period's fractal lattice-structured transactionlogs 266-268.

The fractal lattice-structured transaction logs and the EOP ownershiplogs can be archived every period (e.g., logs 259-263), meaning theactive memory that needs to be referenced to confirm transactions isonly the current versions 264 and 265 of the ownership log (IDP OL) andonly the transactions transmitted to the network for that period(recorded in logs 266, 267, 268).

Additional Validation: Across all copies of each node's transaction log,the net transfers will equal zero. Apart from net increases or decreasesvia the “Airlock”, the total position for any one security will beconstant.

Note: Although there is no requirement to check the EOP results as thefractal lattice-structured transaction logs are self-defining andself-validating, there can be put in place best practices to randomlyselect certain ownership logs and fractal lattice-structured transactionlogs and confirm their EOP hashes with other nodes, or there could be anend-of-day transmission of EOP hashes by every node to the network, forreference and confirmation.

C. Interdependent Linkages

FIG. 28 is a schematic showing interdependent linkages between theownership log of one node (i.e., Node 2) and the fractallattice-structured transaction logs of itself and other nodes at twodifferent times in accordance with one embodiment. As well as thevariable, n-dimensional organizing and linking of the transaction datawithin the fractal lattice data structure, the ownership log and therecreations of all the nodes' transaction logs are linked via inter- andintra-period links. The numbered circles in FIG. 28 indicate thefollowing:

(1) Each contra-transaction is posted to each node's fractal lattice andlinked to the update on the ownership log.

(2) The contra-transactions from both originating nodes arecross-referenced and linked to each other.

(3) Each copy of a node's fractal lattice is hash-linked to the nextperiod's respective transaction logs.

(4) Each copy of a node's ownership log is hash-linked to the nextperiod's respective ownership logs, however, if a node selects to keep alimited number of counterparty transaction log records, its ownershiplog records will be unique to its records so the hash-link betweeninter-period ownership logs would only help its own integrity and wouldnot have to be completed as there is enough integrity from transactionlog links in (2) above and their respective links to the ownership logsin (1) above.

The nature of all the linkages provides the means for any node torecreate the self-validating structure. Any issues with any singlecontra-transaction or ownership log record will create inconsistenciesin the interdependent immutable record.

For example, two contra-transactions for Nodes 1 and 2 are recorded onNode 2's records. One contra-transaction would be posted in Node 2'scopy of the FL transaction log 269 for Node 1 and matched and validatedwith a contra-transaction from Node 2 posted in the FL transaction log270 for Node 2. The two matched and validated contra-transactions wouldbe used to update Node 2's ownership log 272.

At the end of a period the transaction and ownership logs would behash-linked to their next period counter-parties. Node 2's copy of Node1's FL transaction log 269 would be hash-linked to Node 2's copy of Node1's FL transaction log 278 from the next period. Node 2's FL transactionlog 270 would be hash-linked to Node 2's FL transaction log 271 from thenext period. Node 2's ownership log 272 would be hash-linked to Node 2'sownership log 273 for the next period. Similarly transaction logs 274and 275 for one period can be hash-linked with transaction logs 277 and276 respectively for the next period.

D. Future-Dated Period Linkages

FIG. 29 is a schematic illustrating future-dated period linkages linkingtransaction data in a fractal lattice-structured transaction log inaccordance with one embodiment. For future-dated transactions, the logicof processing transactions remains the same except for pre-populatingthe fractal lattice transaction logs and the ownership logs for thatfuture-dated period. The future-dated transactions for each priortransacting period are additive and can be archived each period untilthe “future” date becomes the “current” date and the fractal latticetransaction logs and the ownership logs of that date have entriesrecorded and linked to the prior dated transactions.

FIG. 29 demonstrates how, for one Node's FL, the transactions arerecorded and linked sequentially through the successive prior periods.

If a transaction is represented as Tx a.b.c where: “a” is the period inwhich the transaction is executed; “b” is the period the transaction isto be posted; and “c” is the sequential transaction number (which wouldbe the FL_(—) Address) for the period a.b.

FIG. 29 shows the creation of future-dated and current periodtransactions being sequentially created. For any future-dated FLtransaction log (280, 281), the first transaction recorded as Tx a.b.1(1.1.1, 1.2.1, 1.3.1) will be hash-linked to the Tx_Last of the period(a−1). After the first transactions for any period (279, 280, 281), thesubsequent transactions will be hash-linked to the period's (279) orfuture-dated periods' (280, 281) transactions as per the fractal latticeaddressing and hash-linking as previously described.

For future-dated Period 3 (281): In Period 1 transactions, the firsttransaction (Tx 1.3.1) is hash-linked to the last transaction in Period−1. The transactions (Tx 1.3.1-Tx 1.3.n) are hash linked to each other.For Period 3 transactions executed in 280, the first transaction (Tx2.3.1) is hash linked to the last future-dated transaction 281 fromPeriod 1 (1.3.n). The Period 3 transactions executed in Period 2 (Tx2.3.1-2.3.n) are hash-linked to each other. For Period 3 transactionsexecuted in 281, the first transaction (Tx 3.3.1) is hash linked to thelast future-dated transaction 281 from Period 2 (2.3.n). The Period 3transactions executed in Period 3 (Tx 3.3.1-3.3.n) are hash-linked toeach other.

Most future-dated transactions are expected to be transacted as “short”transfers, which will be filled on the future date. However, it ispossible to record a future-dated transfer on the ownership log, whichwhile reflecting the future obligation, does not create a transfer ofvalue but locks the OL ID as “P”—Payable and identifies the future OL IDas “R”—Receivable.

Network

If “n” is the number of nodes in the network, the distributed ledgerwill be maintained by each node in (n+1) sections:

A transaction log which will consist of one fractal lattice-structureddatabase per network node per asset or asset grouping.

The distributed ledger will include one ownership log database pernetwork node per asset (consistent with the fractal lattice-structuredtransaction logs) listing the current state of all asset ownershippositions.

Note: For contingent transfers there is an additional contingent fractallattice-structured transaction log (FLCtgt) to record the transaction,which when matched is used to generate and broadcast the fourcontra-transactions for the two related bi-directional transfers.

The network will have a set of consensus-approved transaction scriptswithin the network.

The scripts will call the coded versions of the genome sequentialtransaction components, which are the transaction life-cycle buildingblocks.

For each life-cycle script and series of sequential transactioncomponents, the transacting parties will agree upon the parameters to beagreed within the scripts.

Each transacting party's node will independently run the script togenerate its contra-transactions to be broadcast to the network.

The scripts will control the process of transacting parties agreeing totransactions and the data flow to and from each transacting party andeach node.

Where necessary and as defined within the process flows, the script willallow sharing of data across the network to create the two independentcontra-transactions.

The simple coding language used, the small finite number of transactionoptions, the standardized scripts and the independent generation of thecontra-transactions will make it very hard for participants to makeerrors or participate in malfeasant transactions.

The scripts will control the “Account Reveal” process and will referencethe answer against a dataset of transacting parties.

The scripts and the code will allow the transacting party to control thelocking and unlocking of value posted to the ownership logs.

Utilizing a standardized script and agreed parameters for a transaction,each transacting party, via its node, will create a contra-transactionto be broadcast to the network.

Each originating transacting party involved in the transaction has itsnode update its record of the fractal lattice-structured transactionlog.

Each originating node will wait to receive the contra-transaction viathe network

Any node independent (N_(IND)) of the transaction will receive the twocontra-transactions via the network.

For the first transaction received, the independent node NINA willupdate the respective fractal lattice-structured transaction log.

Upon receipt, matching and validation of the second contra-transaction,each node will match and validate the two contra-transactions on theseparate fractal lattice-structured transaction logs per node and willrecord them on the fractal lattice-structured transaction log per thetransaction logic and act according to the contingent flow of the codedtransactions:

For short transfers or short contingent transfers, no further steps arerequired; the nodes will wait for the short “fill” transactions

For transfers, “filled” short transfers, pledges, loans, pledge or loanreturns, the nodes will update their copies of the asset's ownership logaccording to the transaction logic

For contingent versions of transfers, “filled” short transfers, pledges,loans, pledge or loan returns. the nodes will: (1) update and validatethe update of its copies of the respective contingent transfer assetfractal lattice-structured transaction logs for the originating nodes;(2) validate and update its copies of the two respective asset ownershiplogs; and (3) generate and broadcast the two pairs ofcontra-transactions to the network.

The structure of the fractal lattice-structured databases and linkagesbetween the transactions and the ownership log as an expanding record isself-defining and self-validating. The primary requirement of a node isto match and validate transactions, and then record and broadcast thevalidated transactions.

Nodes need to communicate with other local nodes or specific nodes as itrelates to questioning, missing or incomplete transactions ortransactions that cannot be validated.

At the end of a period, before shutting down transmission oftransactions, a node will mark its last transaction as its “Last” orsend an empty (Null) transaction marked “End”, so any other node willthen know its copy of that node's fractal lattice-structured transactionlog is complete.

The workflow for execution and recordation of various financialtransactions will now be described with reference to FIGS. 30 through37, each of which shows workflow in a network comprising one originatingnode that creates the delivery contra-transaction, another originatingnode that creates the receipt contra-transaction and an independent nodethat records the transaction and balances. In each of FIGS. 30 through37, all three nodes end with identical copies of the two fractallattice-structured transaction logs and one ownership log.

For simplicity of coding, the scripts for all types of transactionsfollow the same six fundamental steps: (1) identity confirmation betweenparties; (2) ownership confirmation, when needed for “long”,ledger-referenced value, transactions; (3) transaction data generationby each originating node for their respective transactions; (4)transaction data sharing between transacting parties; (5) transactionposting (by the originating nodes to their records) and broadcast of thetransactions to the network; and (6) receipt, validation and matching oftransactions and posting to transaction logs and the ownership log ofthe non-originating nodes in the network.

Transfer

FIG. 30 is a schematic illustrating asset transfer workflow in a networkcomprising one node that creates the delivery contra-transaction,another node that creates the receipt contra-transaction and anindependent node that records the transaction and balances in accordancewith one embodiment. For FIG. 30 and the other similar, transfer FIGS.31, 32, 34 and 35 the following are consistent elements:

The Nodes are represented as N_Del (285), N_Rec (289) and N_Ind (293).N_Del has its transaction log (286), ownership log (288) and recreatedcopies of N_Rec's transaction log (287). N_Del's transacting partygenerates the TP_Del (297). N_Rec has its transaction log (291),ownership log (292) and recreated copies of N_Del's transaction log(290). N_Rec's transacting party generates the TP_Rec (298). N_Ind hasits ownership log (296) and recreated copies of N_Del's transaction log(294) and N_Rec's transaction log (295).

The respective transfer process steps shown in FIG. 30 and theirassociated logic and control factors are listed in Table 11.

TABLE 11 Asset Transfer Workflow Business and Control Ref TransferProcess Steps Process Logic Factor T1a TP_Del (297) & TP_Rec (298) N/AN/A T1b agree to Transact with each other via Blockchain Network T2TP_Del (297) will reveal its pk & Unique ID Pk identity to TP_Rec (298)and relationship; TP_Rec (298) will confirm Published pk ownership of OLID 1 T3 TP_Del (297) will identify Published pk Pk TP_Rec (298) by itspk T4b1 TP_Rec (298) will be able to SOP OL & IDP Linked, T4b2 confirmfrom N_Rec's (289) OL Ownership published records that TP_Del (297) hasConfirmation and validated the value referenced in the Process Tx's onFL & SOP OL or IDP OL (J) OL T5 TP_Del (297) & TP_Rec (298) ExecutionN/A will execute Tx at some process location (Probably outside (O/sideRqmts) network) T6a1 TP_Del (297) will unlock OL pk, Unique ID pk andT6a2 ID1 and defined T6a3 Encumbrance encumbrance Relationshipmethodology T6b TP_Del (297) will generate OL pk, Unique ID pk and ID 3for Net Amount to be and defined retained by TP_Del (297) Encumbrance OLID Relationship methodology T6c TP_Rec (298) will generate pk, Unique IDpk and OL ID 2 for Amount to be and defined transferred from TP_Del(297) Encumbrance OL ID Relationship methodology T7a1 N_Del (285) &N_Rec (289) Algorithmic FL FL Address T7a2 will identify next sequentialaddress Sequencing T7b2 FL_(Address) for the FL's assignment T7b3 T8a1N_Del (285) & N_Rec (289) Approved, Initially by T8a2 will create andshare Tx data defined Tx script T8b1 elements Script affirmation of T8b2Tx Details. Ultimately by Contra Tx match. T9a N_Del (285) & N_Rec (289)FL Self FL_(Address) and T9b will post the Tx's to their own Definingand #_(Link) FL (D & I) (generating the Self-Validating Hash Linkedrecord) Process T10a N_Del (285) & N_Rec (289) Network Tx Network TxT10b will broadcast the Contra Tx's, broadcasting Send/Receive FLAddresses and Hash Links protocols Controls to the Network T11a1 N_Del(285) will receive, Validation Validation T11a2 validate and matchN_Rec's Process and Tx and Matching T11a3 Contra Tx and post the TxMatching Data fields T11a4 details to N_Del's copy of Control unchanged,N_Rec's FL (287) at the Process; since Tx assigned FL_(Address) andconfirm Ownership creation. the #_(Link) provided. N_Del will TransferLogic post updates to N_Del's OL Summary (288) for the asset for OL ID's1, 2 & 3. T11b1 N_Rec (289) will receive, Validation Validation T11b2validate and match N_Del's Process and Tx and Matching T11b3 Contra Txand post the Tx Matching Data fields T11b4 details to N_Rec's copy ofControl unchanged, N_Del's FL (H) at the assigned Process; since TxFL_(Address) and confirm the it #_(Link) Ownership creation. provided.N_Rec will post Transfer Logic updates to N_Rec's OL (292) Summary forthe asset for OL ID's 1, 2 & 3. T12a1 All N_Ind (293) nodes willValidation Validation T12a2 receive, validate and match Process and Txand Matching T12a3 N_Rec's Contra Tx and post Matching Data fields T12a4the Tx details to N_Ind's copy Control unchanged, T12a5 of N_Rec's FL(295) at the Process; since Tx T12a6 assigned FL_(Address) and confirmOwnership creation. the #_(Link) provided. All N_Ind Transfer Logicnodes will receive, validate and Summary match N_Del's Contra Tx andpost the Tx details to N_Ind's copy of N_Del's FL (294) at the assignedFL_(Address) and confirm the #_(Link) provided. N _Ind will post updatesto N_Ind's OL (296) for the asset for OL ID's 1, 2 & 3.

Pledge

FIG. 31 is a schematic illustrating asset pledge workflow in a networkcomprising one node that creates the delivery contra-transaction,another node that creates the receipt contra-transaction and anindependent node that records the transaction and balances in accordancewith one embodiment. The respective pledge process steps shown in FIG.31 and their associated logic and control factors are listed in Table12.

TABLE 12 Pledge Transfer Workflow Business and Control Ref PledgeProcess Steps Process Logic Factor P1a TP_PLF (311) & TP_PLT (312) N/AN/A P1b agree to Transact a Pledge with each other via BlockchainNetwork P2 TP_PLF (311) will reveal its pk & Unique ID pk identity toTP_PLT (312) and relationship; TP_PLT (312) will confirm Published pkownership of OL ID 1 P3 TP_PLF (311) will identify Published pk pkTP_PLT (312) by its pk P4a TP_PLT (312) will be able to SOP OL & IDPLinked, P4b1 confirm from its N_Rec's (289) OL Ownership publishedrecords that TP_PLF (311) has the Confirmation and validated valuereferenced in the SOP OL or Process Tx's on FL & IDP OL (F) OL P5 TP_PLF(311) & TP_PLT (312) Execution N/A will execute Tx at some locationprocess (Probably outside network) (O/side Rqmts) P6a1 TP_PLF (311) willunlock OL ID1 pk, Unique ID pk and P6a2 and defined P6a3 Encumbranceencumbrance Relationship methodology P6b TP_PLF (311) will generate OLpk, Unique ID pk and ID 3 for Net Amount to be and defined retained byTP_PLF (311) and OL Encumbrance OL ID ID_PLF (F) to reflect the PledgedRelationship methodology commitment to TP_PLT (312) P6c TP_PLT (312)will generate OL pk, Unique ID pk and ID 2 for Amount to be pledged toand defined TP_PLT (312) and OL ID_PLT Encumbrance OL ID (J) to reflectthe pledge return Relationship methodology obligation P7a1 N_Del (285) &N_Rec (289) will Algorithmic FL FL Address P7a2 identify next sequentialFL_(Address) address Sequencing for the FL's assignment P8a1 N_Del (285)& N_Rec (289) will Approved, Initially by P8a2 create and share Tx dataelements defined Tx script P8b1 Script affirmation of P8b2 Tx Details.Ultimately by Contra Tx match. P9a N_Del (285) & N_Rec (289) will FLSelf FL_(Address) and P9b post the Tx's to their own FL's (D Definingand #_(Link) & I) (generating the Hash Linked Self-Validating record).Process P10a N_Del (285) & N_Rec (289) will Network Tx Network Tx P10bbroadcast the Contra Tx's, FL broadcasting Send/Receive Addresses andHash Links to the protocols Controls Network P11a1 N_Del (285) willreceive, validate Validation Validation P11a2 and match N_Rec's (289)Contra Process and and Matching P11a3 Tx and post the Tx details to TxMatching Data fields P11a4 N_Del's (285) copy of N_Rec's FL Controlunchanged, (287) at the assigned FL_(Address) and Process; since Txconfirm the #_(Link) provided. N_Del Ownership creation. will postupdates to N_Del's OL Transfer Logic (288) for the asset for OL ID's 1,Summary 2, 3, PLF & PLT. P11b1 N_Rec (289) will receive, validateValidation Validation P11b2 and match N_Del's (285) Contra Process andand Matching P11b3 Tx and post the Tx details to Tx Matching Data fieldsP11b4 N_Rec's (287) copy of N_Del's FL Control unchanged, (H) at theassigned FL_(Address) and Process; since Tx confirm the #_(Link)provided. N_Rec Ownership creation. (289) will post updates to N_Rec'sTransfer Logic (289) OL for the asset for OL ID's Summary 1, 2, 3, PLF &PLT. P12b1 All N_Ind (293) nodes will Validation Validation P12b2receive, validate and match Process and and Matching P12b3 N_Rec's (289)Contra Tx and post Tx Matching Data fields P12b4 the Tx details to N_Ind's (293) Control unchanged, P12b5 copy of N_Rec's FL (295) at theProcess; since Tx P12b6 assigned FL_(Address) and confirm the Ownershipcreation. #_(Link) provided. All N_Ind (293) Transfer Logic nodes willreceive, validate and Summary match N_Del's (285) Contra Tx and post theTx details to N _Ind's (293) copy of N_Del's FL (294) at the assignedFL_(Address) and confirm the #_(Link) provided. N_Ind (293) will postupdates to N_Ind's OL (296) for the asset for OL ID's 1, 2, 3, PLF &PLT.

Loan

FIG. 32 is a schematic illustrating loan process workflow in a networkcomprising one node that creates the delivery contra-transaction,another node that creates the receipt contra-transaction and anindependent node that records the transaction and balances in accordancewith one embodiment. The respective loan process steps shown in FIG. 32and their associated logic and control factors are listed in Table 13.

TABLE 13 Loan Process Workflow Business and Control Ref Loan ProcessSteps Process Logic Factor L1a TP_L (323) & TP_B (324) agree N/A N/A L1bto Transact a Pledge with each other via Blockchain Network L2 TP_L(323) will reveal its pk & Unique ID pk identity to TP_B (324) andrelationship; TP_B (K) will confirm Published pk ownership of OL ID 1 L3TP_L (323) will identify TP_B Published pk pk (324) by its pk L4a TP_B(K) will be able to SOP OL & IDP Linked, L4b1 confirm from its N_Rec'sOL Ownership published records that TP_L (323) has the Confirmation andvalidated value referenced in the SOP OL Process Tx's on FL & or IDP OLOL L5 TP_L (323) & TP_B (324) will Execution N/A execute Tx at somelocation process (Probably outside network) (O/side Rqmts) L6a1 TP_L(323) will unlock OL ID1 pk, Unique ID pk and L6a2 and defined L6a3Encumbrance encumbrance Relationship methodology L6b TP_L (323) willgenerate OL ID pk, Unique ID pk and 3 for Net Amount to be retained anddefined by TP_L (323) and OL ID_L to Encumbrance OL ID reflect the Loanmade to TP_B Relationship methodology (324) L6c TP_B (324) will generateOL ID pk, Unique ID pk and 2 for Amount to be loaned to and defined TP_B(324) and OL ID_B to Encumbrance OL ID reflect the Borrow from TP_LRelationship methodology (323) L7a1 N_Del (285) & N_Rec (289)Algorithmic FL FL Address L7a2 will identify next sequential addressSequencing FL_(Address) for the FL's assignment L8a1 N_Del (285) & N_Rec(289) Approved, Initially by L8a2 will create and share Tx data definedTx script L8b1 elements Script affirmation of L8b2 Tx Details.Ultimately by Contra Tx match. L9a N_Del (285) & N_Rec (289) FL SelfFL_(Address) and L9b will post the Tx's to their own Defining and#_(Link) FL (D & I) (generating the Hash Self-Validating Linked record).Process L10a N_Del (285) & N_Rec (289) Network Tx Network Tx L10b willbroadcast the Contra Tx's, broadcasting Send/Receive FL Addresses andHash Links to protocols Controls the Network L11a1 N_Del (285) willreceive, Validation Validation L11a2 validate and match N_Rec's Processand and Matching L11a3 (289) Contra Tx and post the Tx Tx Matching Datafields L11a4 details to N_Del's (285) copy of Control unchanged, N_Rec'sFL (287) at the Process; since Tx assigned FL_(Address) and confirmOwnership creation. the #_(Link) provided. N_Del (285) Transfer Logicwill post updates to N_Del's OL Summary (288) for the asset for OL ID's1, 2, 3, B & L. L11b1 N_Rec (289) will receive, Validation ValidationL11b2 validate and match N_Del's Process and and Matching L11b3 (285)Contra Tx and post the Tx Tx Matching Data fields L11b4 details toN_Rec's (289) copy of Control unchanged, N_Del's FL (290) at theassigned Process; since Tx FL_(Address) and confirm the #_(Link)Ownership creation. provided. N_Rec (289) will post Transfer Logicupdates to N_Rec's OL (292) for Summary the asset for OL ID's 1, 2,3, B& L. L12b1 All N_Ind nodes will receive, Validation Validation L12b2validate and match N_Rec's Process and and Matching L12b3 Contra Tx andpost the Tx Tx Matching Data fields L12b4 details to N_Ind's copy ofControl unchanged, L12b5 N_Rec's FL at the assigned Process; since TxL12b6 FL_(Address) and confirm the #_(Link) Ownership creation.provided. All N_Ind nodes will Transfer Logic receive, validate andmatch Summary N_Del's Contra Tx and post the Tx details to N_Ind's copyof N_Del's FL at the assigned FL_(Address) and confirm the #_(Link)provided. N _Ind will post updates to N_Ind's OL for the asset for OLID's 1, 2,3, Borrow & Loan.

Contingent Transfer

FIG. 33 is a schematic illustrating contingent transfer workflow in anetwork comprising one node that creates the deliverycontra-transaction, another node that creates the receiptcontra-transaction and an independent node that records the transactionand balances in accordance with one embodiment. For FIG. 33 and theother similar, transfer FIGS. 36 and 37 the following are consistentelements:

The Nodes are represented as N_ABBA (325), N_BAAB (330) and N_Ind (334).N_ABBA has its contingent transfer transaction log (326), ownership logsfor assets AB and BA (328) and recreated copies of N_BAAB's contingenttransfer transaction log (327). N_ABBA's transacting party generates theTP_ABBA (329). N_BAAB has its contingent transfer transaction log (332),ownership logs for assets AB and BA (333) and recreated copies ofN_ABBA's contingent transfer transaction log (331). N_BAAB's transactingparty generates the TP_BAAB (335). N_Ind has its ownership logs forassets AB and BA (338) and recreated copies of N_ABBA's transaction log(336) and N_BAAB's transaction log (337).

The respective contingent transfer process steps shown in FIG. 33 andtheir associated logic and control factors are listed in Table 14.

TABLE 14 Contingent Transfer Workflow Contingent Transfer ProcessBusiness and Control Ref Steps Process Logic Factor C1a TP_ABBA (329) &TP_BAAB N/A N/A C1b (335) agree to Transact a Contingent Transfer witheach other via Blockchain Network C2a TP_ABBA (329) will reveal its pk &Unique ID pk C3a identity to TP_BAAB (335) and relationship; TP_BAAB(335) will confirm Published pk ownership of OL ID AB C2b TP_BAAB (329)will reveal its pk & Unique ID pk C3b identity to TP_ABBA (329) andrelationship; TP_ABBA (329) will confirm Published pk ownership of OL IDBA C4a TP_ABBA (329) will be able to SOP OL & IDP Linked, confirm fromits N_ABBA's (325) OL Ownership published records that TP_BAAB (335) hasConfirmation and validated the value referenced in the SOP Process Tx'son FL & OL or IDP OL (F) as OL ID OL 1_BA C4b TP_BAAB (335) will be ableto SOP OL & IDP Linked, confirm from its N_BAAB's (330) OL Ownershippublished records that TP_ABBA (329) has Confirmation and validated thevalue referenced in the SOP Process Tx's on FL & OL or IDP OL (J) as OLID 1_AB OL C5 TP_ABBA (329) & TP_BAAB Execution N/A (335) will executeTx at some process location (Probably outside (O/side Rqmts) network)C6a1 TP_ABBA (329) will unlock OL pk, Unique ID pk and C6a2 ID 1_AB anddefined C6a3 Encumbrance encumbrance Relationship methodology C6b1TP_BAAB (335) will unlock OL pk, Unique ID pk and C6b2 ID 1_BA anddefined C6b3 Encumbrance encumbrance Relationship methodology C6bTP_ABBA (329) will generate pk, Unique ID pk and OL ID 3_AB for NetAmount to and defined be retained by TP_ABBA (329) Encumbrance OL ID andOL ID 2_BA to be transferred Relationship methodology from TP_BAAB (335)C6c TP_BAAB (335) will generate pk, Unique ID pk and OL ID 3_BA for NetAmount to and defined be retained by TP_BAAB (335) Encumbrance OL ID andOL ID 2_AB to be transferred Relationship methodology from TP_ABBA (329)C7a1 N_ABBA (325) will identify next Algorithmic FL FL Address C7a2sequential FLAddress for address Sequencing N_ABBA's (325) FL_Cntg (D)assignment C7b1 N_BAAB (330) will identify next C7b2 sequentialFL_(Address) for N_BAAB'a (330) FL_Ctng (I) C8a1 N_ABBA (325) willcreate and Approved, Initially by C8a2 share Tx_ABBA data elementsdefined Tx script Script affirmation of Tx Details. Ultimately by ContraTx match. C8b1 N _ BAAB (330) will create and Approved , Initially byC8b2 share Tx_BAAB data elements defined Tx script Script affirmation ofTx Details. Ultimately by Contra Tx match. C9a N_ABBA (325) will postthe FL Self FL_(Address) and Tx_ABBA to N_ABBA's Defining and #_(Link)FL_Ctng (D) (generating the Hash Self-Validating Linked record). ProcessC9b N_BAAB (330) will post the FL Self FL_(Address) and Tx_BAAB toN_BAAB's Defining and #_(Link) FL_Ctng (I) (generating the HashSelf-Validating Linked record). Process C10a N_ABBA (325) & N_BAABNetwork Tx Network Tx C10b (330) will broadcast the Contra broadcastingSend/Receive Tx's, FL Addresses and Hash protocols Controls Links to theNetwork C11a1 N_ABBA (325) will receive, Validation Validation C11a2validate and match N_BAAB's Process and and Matching C11a3 (330) ContraTx and post the Tx Tx Matching Data fields C11a4 details to N_ABBA's(325) copy Control unchanged, of N_BAAB's FL_Ctng (327) at Process;since Tx the assigned FL_(Address) and confirm Ownership creation. the#_(Link) provided. N_ABBA Transfer Logic (325) will post Tx_Del detailsto Summary N_ABBA's FL_AB (326)and Tx_Rec to N_ABBA's copy of N- BAAB'sFL_AB (327) and will post Tx_Rec details to N_ABBA's FL_BA (326) andTx_Del to N_ABBA's copy of N-BAAB's FL_BA (327). N_ABBA will postupdates to N_ABBA's OL (328) for the Asset AB OL ID's 1_AB, 2_AB, 3_ABand Asset BA OL ID's 1_BA, 2_BA, #_BA C11b1 N_BAAB (330) will receive,Validation Validation C11b2 validate and match N_ABBA's Process and andMatching C11b3 (325) Contra Tx and post the Tx Tx Matching Data fieldsC11b4 details to N_BAAB's (330) copy Control unchanged, of N_ABBA'sFL_Ctng (331) at Process; since Tx the assigned FL_(Address) and confirmOwnership creation. the #_(Link) provided. N_BAAB Transfer Logic (330)will post Tx_Rec details to Summary N_BAAB's FL_AB (332) and Tx_Del toN_BAAB's copy of N- ABBA's FL_AB (331) and will post Tx_Del details toN_BAAB's FL_BA (332) and Tx_Rec to N_BAAB's copy of N-ABBA's FL_BA(331). N_BAAB will post updates to N_BAAB's OL (333) for the Asset AB OLID's 1_AB, 2_AB, 3_AB and Asset BA OL ID's 1_BA, 2_BA, 3BA C12c1 AllN_Ind (293) nodes will Validation Validation C12c2 receive, validate andmatch Process and and Matching C12c3 N_BAAB's (330) Contra Tx MatchingData fields C12c4 Tx_BAAB and post the Control unchanged, C12c5 Tx_BAABdetails to N_Ind's copy Process; since Tx of N_BAAB's FL_Ctng (M) at theOwnership creation. assigned FL_(Address) and confirm the Transfer Logic#_(Link) provided. Summary All N_Ind (293) nodes will receive, validateand match N_ABBA's (325) Contra Tx_ABBA and post the Tx_ABBA details toN_Ind's copy of N_ABBAI's FL_Cntg (L) at the assigned FL_(Address) andconfirm the #_(Link) provided. C13a N_ABBA (325) and N_BAAB ValidationValidation C13b (330) will independently create Process and and Matchingand broadcast N_ABBA- Tx Matching Data fields Tx_Del_AB, N_BAAB- Controlunchanged, Tx_Rec_AB, N_BAAB- Process; since Tx Tx_Del_BA, N_ABBA-Ownership creation. Tx_Rec_BA Transfer Logic Summary C14c1 All N_Ind(293) Nodes will Validation Validation C14c2 receive, validate and matchProcess and and Matching C14c3 Tx_Del_AB, N_BAAB- Tx Matching Datafields C14c4 Tx_Rec_AB, N_BAAB- Control unchanged, C14c5 Tx_Del_BA,N_ABBA- Process; since Tx Tx_Rec_BA. N_Ind (293) will Ownershipcreation. post Tx_Del details to N_Ind's Transfer Logic copy of N_ABBA'sFL_AB (Y1) Summary and Tx_Rec to N_Ind's copy of N- BAAB's FL_AB (Z1)and will post Tx_Del details to N_Ind's copy of N_BAAB's FL_BA (Z2) andTx_Rec to N_Ind's copy of N- ABBA's FL_BA (Y2). N_Ind (293) will postupdates to N _Ind's OL (N) for the Asset AB OL ID's 1_AB, 2_AB, 3_AB andAsset BA OL ID's 1_BA, 2_BA, 3BA

Short Transfer

FIG. 34 is a schematic illustrating short transfer workflow in a networkcomprising one node that creates the delivery contra-transaction,another node that creates the receipt contra-transaction and anindependent node that records the transaction and balances in accordancewith one embodiment. The respective short transfer process steps shownin FIG. 34 and their associated logic and control factors are listed inTable 15.

TABLE 15 Short Transfer Workflow Business and Control Ref Short TransferProcess Steps Process Logic Factor ST1a TP_Del & TP_Rec agree to N/A N/AST1b Transact with each other via Blockchain Network, however, TP_Deldoes not have the value to transfer. The value may be specified orunspecified, variable dependent and Future-Dated. ST2 TP_Rec willidentify TP Del by Published pk pk ST3 it pk TP_Del (344) will identifyPublished pk pk TP_Rec (348) by its pk ST4 N/A SOP OL & IDP Linked, OLOwnership published Confirmation and validated Process Tx's on FL & OLST5 TP_Del (344) & TP_Rec (348) Execution N/A will execute Tx at somelocation process (Probably outside network) (O/side Rqmts) ST6a N/A pk,Unique ID pk and and defined Encumbrance encumbrance Relationshipmethodology ST6b N/A pk, Unique ID pk and and defined Encumbrance OL IDRelationship methodology ST6c TP_Rec (348) will generate OL pk, UniqueID pk and ID 2 for Amount (Unspecified, and defined Variable-Dependentor Future- Encumbrance OL ID Dated) to be transferred from Relationshipmethodology TP_Del (344) ST7a1 N_Del (285) & N_Rec (289) willAlgorithmic FL FL Address ST7a2 identify next sequential FL_(Address)address Sequencing ST7b1 for the FL's assignment ST7b2 ST8a1 N_Del (285)& N_Rec (289) will Approved, Initially by ST8a2 create and share Tx datadefined Tx script ST8b1 elements Script affirmation of ST8b2 Tx Details.Ultimately by Contra Tx match. ST9a N_Del (285) will post the Tx to FLSelf FL_(Address) and ST9b N-Del FL (D) & N_Rec (289) Defining and#_(Link) will post the Tx to N-Recl FL (I) Self-Validating (generatingthe Hash Linked Process records) ST10a N_Del (285) & N_Rec (289) willNetwork Tx Network Tx ST10b broadcast the Short Contra Tx's,broadcasting Send/Receive FL Addresses and Hash Links to protocolsControls the Network ST11a1 N_Del (285) will receive, ValidationValidation ST11a2 validate and match N_Rec's Process and and MatchingST11a3 (289) Contra Tx and post the Tx Tx Matching Data fields detailsto N_Del's copy of Control unchanged, N_Rec's FL (E) at the assignedProcess; since Tx FL_(Address) and confirm the #_(Link) Ownershipcreation. provided. Transfer Logic Summary ST11b1 N_Rec (289) willreceive, Validation Validation ST11b2 validate and match N_Del's Processand and Matching ST11b3 (285) Contra Tx and post the Tx Tx Matching Datafields details to N_Rec's copy of Control unchanged, N_Del's FL (H) atthe assigned Process; since Tx FL_(Address) and confirm the #_(Link)Ownership creation. provided. Transfer Logic Summary ST12a1 All N_Ind(293) nodes will Validation Validation ST12a2 receive, validate andmatch Process and and Matching ST12a3 N_Rec's (289) Contra Tx and TxMatching Data fields ST12a4 post the Tx details to N_Ind's Controlunchanged, ST12a5 copy of N_Rec's FL (295) at the Process; since Txassigned FL_(Address) and confirm Ownership creation. the #_(Link)provided. All N_Ind Transfer Logic (293) nodes will receive, validateSummary and match N_Del's (285) Contra Tx and post the Tx details toN_Ind's copy of N_Del's FL (294) at the assigned FL_(Address) andconfirm the #_(Link) provided.

Short Transfer Fill

FIG. 35 is a schematic illustrating short transfer fill workflow in anetwork comprising one node that creates the deliverycontra-transaction, another node that creates the receiptcontra-transaction and an independent node that records the transactionand balances in accordance with one embodiment. The respective shorttransfer fill process steps shown in FIG. 35 and their associated logicand control factors are listed in Table 16.

Assume TP_AB that was short in the previous transaction is now filled byTP_AB. With a short fill, a transfer creating OL ID 1 referencing the“short” FL_Address and 2 and generated OL ID 3 (if necessary), of theshort position to be transferred, a new “long” transaction with bothcontra-transactions posted to the fractal lattice-structured transactionlog and referenced OL ID 2 can allow steps T6 a 1 thru T12 a 6 to becompleted within the transfer flow and the short to be filled.

TABLE 16 Short Transfer Fill Workflow Business and Control Ref ShortTransfer Fill Process Steps Process Logic Factor FT1a TP_Del (358) willidentify an OL ID 1 N/A N/A FT1b to fill the short and communicate it toTP_Rec FT2 TP_Del (358) will confirm its identity pk & Unique ID pk toTP_Rec (363) via the OL ID relationship; Published pk FT3 TP_Del (358)will identify TP_Rec Published pk pk (363) by its pk FT4b1 TP_Rec (363)will be able to confirm SOP OL & IDP Linked, FT4b2 from N_Rec's (289)records that OL Ownership published TP_Del (358) has the valueConfirmation and validated referenced in the SOP OL or IDP Process Tx'son FL & OL (J) OL FTS N/A Execution N/A process (O/side Rqmts) FT6a1TP_Del (358) will unlock OL ID1 pk, Unique ID pk and FT6a2 and definedFT6a3 Encumbrance encumbrance Relationship methodology FT6b TP_Del (358)will generate OL ID 3 pk, Unique ID pk and for Net Amount to be retainedby and defined TP_Del (358) Encumbrance OL ID Relationship methodologyFT6c TP_Rec (363) will use previously pk, Unique ID pk and generated OLID 2 for Amount to be and defined transferred from TP_Del (358)Encumbrance OL ID Relationship methodology FT7a1 N_Del (285) & N_Rec(289) will Algorithmic FL FL Address FT7a2 identify next sequentialFL_(Address) for address Sequencing FT7b2 the FL's assignment FT7b3FT8a1 N_Del (285) & N_Rec (289) will Approved, Initially by FT8a2 createand share Tx data elements defined Tx script FT8b1 Script affirmation ofFT8b2 Tx Details. Ultimately by Contra Tx match. FT9a N_Del (285) &N_Rec (289) will post FL Self FL_(Address) and FT9b the Tx's to theirown FL (D & I) Defining and #_(Link) (generating the Hash Linked record)Self-Validating and referencing FL_ID and Process FL_Address of ShortTx. FT10a N_Del (285) & N_Rec (B) will Network Tx Network Tx FT10bbroadcast the Contra Tx's, FL broadcasting Send/Receive Addresses andHash Links to the protocols Controls Network. FT11a1 N_Del (285) willreceive, validate Validation Validation FT11a2 and match N_Rec's ContraTx and Process and and Matching FT11a3 post the Tx details to N_Del'scopy Tx Matching Data fields FT11a4 of N_Rec's FL (E), referencingControl unchanged, FL_ID and FL_Address of the Short Process; since TxTx, at the assigned FL_(Address) and Ownership creation. confirm the#_(Link) provided. N_Del will Transfer Logic post updates to N_Del's OL(288) Summary for the asset for OL ID's 1, 2 & 3. FT11b1 N_Rec (289)will receive, validate Validation Validation FT11b2 and match N_Del'sContra Tx and Process and and Matching FT11b3 post the Tx details toN_Rec's copy Tx Matching Data fields FT11b4 of N_Del's FL (H),referencing Control unchanged, FL_ID and FL_Address of the ShortProcess; since Tx Tx, at the assigned FL_(Address) and Ownershipcreation. confirm the #_(Link) provided. N_Rec Transfer Logic will postupdates to N_Rec's OL (J) Summary for the asset for OL ID's 1, 2 & 3.FT12a1 All N_Ind (293) nodes will receive, Validation Validation FT12a2validate and match N_Rec's Contra Process and and Matching FT12a3 Tx andpost the Tx details to Tx Matching Data fields FT12a4 N_Ind's copy ofN_Rec's FL (295), Control unchanged, FT12a5 referencing FL_ID andFL_Address Process; since Tx FT12a6 of the Short Tx, at the assignedOwnership creation. FL_(Address) and confirm the #_(Link) Transfer Logicprovided. Summary All N_Ind nodes will receive, validate and matchN_Del's Contra Tx and post the Tx details to N_Ind's copy of N_Del's FL(294), referencing FL_ID and FL_Address of the Short Tx, at the assignedFL_(Address) and confirm the #_(Link) provided. N_Ind will post updatesto N_Ind's OL (296) for the asset for OL ID's 1, 2 & 3.

Short Contingent Transfer

FIG. 36 is a schematic illustrating short contingent transfer workflowin a network comprising one node that creates the deliverycontra-transaction, another node that creates the receiptcontra-transaction and an independent node that records the transactionand balances in accordance with one embodiment. The respective shortcontingent transfer process steps shown in FIG. 36 and their associatedlogic and control factors are listed in Table 17.

TABLE 17 Short Contingent Transfer Workflow Short Contingent TransferProcess Business and Control Ref Steps Process Logic Factor SC1a TP_ABBA(391) & TP_BAAB N/A N/A SC1b (392) agree to Transact a ContingentTransfer with each other via Blockchain Network. TP_ABBA (391) willdeliver AB, “Short” vs receiving BA, “Long” from TP_BAAB (392). SC2aTP_BAAB (392) will reveal its pk & Unique ID pk identity to TP_ABBA(391) via relationship; TP_BAAB's (392) pk linked to Published pk OL ID1 for BA and TP_ABBA (391) will confirm ownership of OL ID 1 for BA SC2bTP BAAB (392) will confirm Published pk pk TP_ABBA's (391) identity byits SC3a pk TP_ABBA (391) will be able SOP OL & IDP Linked, SC4a toconfirm from its N_ABBA's OL Ownership published (325) records thatTP_BAAB Confirmation and validated (392) has the value referenced inProcess Tx's on FL & the SOP OL or IDP OL as OL OL ID 1_BA SC4b N/A SOPOL & IDP Linked, OL Ownership published Confirmation and validatedProcess Tx's on FL & OL SC5 TP_ABBA (391) & TP_BAAB Execution N/A (392)will execute Tx at some process location (Probably outside (O/sideRqmts) network) SC6b1 TP_BAAB (392) will unlock OL pk, Unique ID pk andSC6b2 ID 1_BA and defined SC6b3 Encumbrance encumbrance Relationshipmethodology SC6a3 TP_ABBA (391) will generate pk, Unique ID pk and OL ID3_AB for Net Amount and defined (TBD) to be retained by Encumbrance OLID TP_ABBA (391) and TP_ABBA Relationship methodology (391) willgenerate OL ID 2_BA for amount to be received from TP_BAAB (392) SC6b4TP_BAAB (392) will generate pk, Unique ID pk and OL ID 3_BA for NetAmount to and defined be retained by TP_BAAB (392) Encumbrance OL ID andTP_BAAB (392) will Relationship methodology generate OL ID 2_AB forAmount to be received from TP_ABBA (391) SC7a1 N_ABBA (325) willidentify Algorithmic FL FL Address SC7a2 next sequential FL_(Address)for address Sequencing N_ABBA's (325) FL_Cntg (D) assignment SC7b1N_BAAB (330) will identify Algorithmic FL FL Address SC7b2 nextsequential FL_(Address) for address Sequencing N_BAAB's (330) FL_Ctng(I) assignment SC8a1 N_ABBA (325) will create and Approved, Initially bySC8a2 share transaction Tx_ABBA data defined Tx script elements Scriptaffirmation of Tx Details. Ultimately by Contra Tx match. SC8b1 N_BAAB(330) will create and Approved, Initially by SC8b2 share transactionTx_BAAB data defined Tx script elements Script affirmation of TxDetails. Ultimately by Contra Tx match. SC9a N_ABBA will post the FLSelf FL_(Address) and Tx_ABBA to N_ABBA's Defining and #_(Link) FL_Ctng(326) (generating the Self-Validating Hash Linked record). Process SC9bN_BAAB will post the FL Self FL_(Address) and Tx_BAAB to N_BAAB'sDefining and #_(Link) FL_Ctng (332) (generating the Self-Validating HashLinked record). Process SC10a N_ABBA & N_BAAB will Network Tx Network TxSC10b broadcast the Short Contra Tx's, broadcasting Send/Receive FLAddresses and Hash Links to protocols Controls the Network SC11a1 N_ABBA(325) will receive, Validation Validation SC11a2 validate and matchN_BAAB's Process and and Matching SC11a3 (330) Short Cntg Contra Tx andTx Matching Data fields post the Tx details to N_ABBA's Controlunchanged, (325) copy of N_BAAB's Process; since Tx FL_Ctng (327) at theassigned Ownership creation. FL_(Address) and confirm the Transfer Logic#_(Link) provided. Summary SC11b1 N_BAAB (330) will receive, ValidationValidation SC11b2 validate and match N_ABBA's Process and and MatchingSC11b3 (325) Short Cntg Contra Tx and Tx Matching Data fields post theTx details to N_BAAB's Control unchanged, (330) copy of N_ABBA'sProcess; since Tx FL_Ctng (331) at the assigned Ownership creation.FL_(Address) and confirm the Transfer Logic #_(Link) provided. SummarySC12c1 All N_Ind (334) nodes will Validation Validation SC12c2 receive,validate and match Process and and Matching SC12c3 N_ABBA's (325) ShortCtng Tx Matching Data fields SC12c4 Contra Tx_ABBA and post the Controlunchanged, SC12c5 Tx_ABBA details to N_Ind's Process; since Tx (334)copy of N_ABBA's Ownership creation. FL_Cntg (336) at the assignedTransfer Logic FL_(Address) and confirm the #_(Link) Summary provided.All N_Ind (334) nodes will receive, validate and match N_BAAB's (330)Short Ctng Contra Tx_BAAB and post the Tx_BAAB details to N_Ind's (334)copy of N_BAAB's FL_Ctng (337) at the assigned FL_(Address) and confirmthe #_(Link) provided. SC13 N/A SC14 N/A

Short Contingent Transfer Fill

FIG. 37 is a schematic illustrating short contingent transfer fillworkflow in a network comprising one node that creates the deliverycontra-transaction, another node that creates the receiptcontra-transaction and an independent node that records the transactionand balances in accordance with one embodiment. The respectivecontingent transfer fill process steps shown in FIG. 37 and theirassociated logic and control factors are listed in Table 18.

TABLE 18 Short Contingent Transfer Fill Workflow Short ContingentTransfer Fill Business and Control Ref Process Steps Process LogicFactor FC1a TP_ABBA (393) wil identfy N/A N/A FC1b AB OL ID1 to fillTP_AB Short and communicate it to TP_BAAB (394). FC2a TP_ABBA (393) willconfirm pk & Unique ID pk FC3a its identity to TP_BAAB (394)relationship; and TP_BAAB (394) will re- Published pk confirm ownershipof OL ID AB FC2b TP_BAAB (393) will reveal its pk & Unique ID pk FC3bidentity to TP_BAAB (394) relationship; and TP_ABBA (393) will Publishedpk re-confirm ownership of OL ID BA FC4a TP_ABBA (393) will be able SOPOL & IDP Linked, to re-confirm from its OL Ownership published N_ABBA's(325) records that Confirmation and validated TP_BAAB (394) has thevalue Process Tx's on FL & referenced in the SOP OL or OL IDP OL (F) asOL ID 1_BA FC4b TP_BAAB (394) will be able SOP OL & IDP Linked, tore-confirm from its OL Ownership published N_BAAB's (330) records thatConfirmation and validated TP_ABBA (393) has the value Process Tx's onFL & referenced in the SOP OL or OL IDP OL (J) as OL ID 1_AB FC5 N/AExecution N/A process (O/side Rqmts) FC6a1 TP_ABBA (393) will unlock pk,Unique ID pk and FC6a2 OL ID 1_AB and defined FC6a3 Encumbranceencumbrance Relationship methodology FC6b1 TP_BAAB (394) will unlock pk,Unique ID pk and FC6b2 OL ID 1_BA and defined FC6b3 Encumbranceencumbrance Relationship methodology FC6b TP_ABBA (393) will generatepk, Unique ID pk and OL ID 3_AB for Net Amount and defined to beretained by TP_ABBA Encumbrance OL ID (393) and OL ID 2_BA to beRelationship methodology transferred from TP_BAAB (394) FC6c TP_BAAB(394) will generate pk, Unique ID pk and OL ID 3_BA for Net Amount anddefined to be retained by TP_BAAB Encumbrance OL ID (394) and OL ID 2_ABto be Relationship methodology transferred from TP_ABBA (393) FC7a1N_ABBA (325) will identify Algorithmic FL FL Address FC7a2 nextsequential FL_(Address) for address Sequencing N_ABBA's (325) FL_Cntg(D) assignment FC7b1 N_BAAB (330) will identify FC7b2 next sequentialFLAddress for N_BAAB'a (330) FL_Ctng (I) FC8a1 N_ABBA (325) will createand Approved, Initially by FC8a2 share Tx_ABBA data elements defined Txscript Script affirmation of Tx Details. Ultimately by Contra Tx match.FC8b1 N_BAAB (330) will create and Approved, Initially by FC8b2 shareTx_BAAB data elements defined Tx script Script affirmation of TxDetails. Ultimately by Contra Tx match. FC9a N_ABBA (325) will post theFL Self FL_(Address) and Tx_ABBA to N_ABBA's Defining and #_(Link)FL_Ctng (D) (generating the Self-Validating Hash Linked record). ProcessFC9b N_BAAB (330) will post the FL Self FL_(Address) and Tx_BAAB toN_BAAB's Defining and #_(Link) FL_Ctng (I) (generating theSelf-Validating Hash Linked record). Process FC10a N_ABBA (325) & N_BAABNetwork Tx Network Tx FC10b (330) will broadcast the Contra broadcastingSend/Receive Tx's, FL Addresses and Hash protocols Controls Links to theNetwork FC11a1 N_ABBA (325) will receive, Validation Validation FC11a2validate and match N_BAAB's Process and and Matching FC11a3 (330) ContraTx and post the Tx Matching Data fields FC11a4 Tx details to N_ABBA's(325) Control unchanged, copy of N_BAAB's FL_Ctng Process; since Tx(327) at the assigned FL_(Address) Ownership creation. and confirm the#_(Link) provided. Transfer Logic N_ABBA (325) will post Summary Tx_Deldetails to N_ABBA's FL_AB (326) and Tx_Rec to N_ABBA's copy of N-BAAB'sFL_AB (327) and will post Tx_Rec details to N_ABBA's FL_BA (326) andTx_Del to N_ABBA's copy of N-BAAB's FL_BA (327). N_ABBA will postupdates to N_ABBA's OL (328) for the Asset AB OL ID's 1_AB, 2_AB(Referencing the Short Tx FL Details), 3_AB and Asset BA OL ID's l_BA,2_BA, #_BA FC11b1 N_BAAB (330) will receive, Validation ValidationFC11b2 validate and match N_ABBA's Process and and Matching FC11b3 (325)Contra Tx and post the Tx Matching Data fields FC11b4 Tx details toN_BAAB's (330) Control unchanged, copy of N_ABBA's FL_Ctng Process;since Tx (331) at the assigned FL_(Address) Ownership creation. andconfirm the #_(Link) provided. Transfer Logic N_BAAB (330) will postSummary Tx_Rec details to N_BAAB's FL_AB (332) and Tx_Del to N_BAAB'scopy of N-ABBA's FL_AB (331) and will post Tx_Del details to N_BAAB'sFL_BA (332) and Tx_Rec to N_BAAB's copy of N-ABBA's FL_BA (331). N_BAABwill post updates to N_BAAB's OL (333) for the Asset AB OL ID's 1_AB,2_AB (Referencing the Short Tx FL Details), 3_AB and Asset BA OL ID's1_BA, 2_BA, 3BA FC12c1 All N_Ind (334) nodes will Validation ValidationFC12c2 receive, validate and match Process and and Matching FC12c3N_BAAB's (330) Contra Tx Matching Data fields FC12c4 Tx_BAAB and postthe Control unchanged, FC12c5 Tx_BAAB details to N_Ind's Process; sinceTx copy of N_BAAB's FL_Ctng Ownership creation. (337) at the assignedFL_(Address) Transfer Logic and confirm the #_(Link) provided. SummaryAll N_Ind (334) nodes will receive, validate and match N_ABBA's (325)Contra Tx_ABBA and post the Tx_ABBA details to N_Ind's copy of N_ABBAI'sFL_Cntg (336) at the assigned FL_(Address) and confirm the #_(Link)provided. FC13a N_ABBA (325) and N_BAAB Validation Validation FC13b(330) will independently create Process and and Matching and broadcastN_ABBA- Tx Matching Data fields Tx_Del_AB, N_BAAB- Control unchanged,Tx_Rec_AB, N_BAAB- Process; since Tx Tx_Del_BA, N_ABBA- Ownershipcreation. Tx_Rec_BA Transfer Logic Summary FC14c1 All N_Ind (334) Nodeswill Validation Validation FC14c2 receive, validate and match Processand and Matching FC14c3 Tx_Del_AB, N_BAAB- Tx Matching Data fieldsFC14c4 Tx_Rec_AB, N_BAAB- Control unchanged, FC14c5 Tx_Del_BA, N_ABBA-Process; since Tx Tx_Rec_BA. N_Ind (334) will Ownership creation. postTx_Del details to N_Ind's Transfer Logic copy of N_ABBA's FL_AB Summary(FC14c3) and Tx_Rec to N_Ind's copy of N-BAAB's FL_AB (FC14c4) and willpost Tx_Del details to N_Ind's copy of N_BAAB's FL_BA (FC14c4) andTx_Rec to N_Ind's copy of N-ABBA's FL_BA (FC14c3). N_Ind (C) will postupdates to N_Ind's OL (338) for the Asset AB OL ID's 1_AB, 2_AB(Referencing the Short Tx FL Details), 3_AB and Asset BA OL ID's 1_BA,2_BA, 3BA

While distributed ledgers for financial services transactions thatutilize blockchain technology have been described with reference tovarious embodiments, it will be understood by those skilled in the artthat various changes may be made and equivalents may be substituted forelements thereof without departing from the teachings herein. Inaddition, many modifications may be made to adapt the concepts andreductions to practice disclosed herein to a particular situation.Accordingly, it is intended that the subject matter covered by theclaims not be limited to the disclosed embodiments.

As used in the claims, the term “node” refers to a computer systemcomprising at least one computer or processor, a non-transitory tangiblecomputer-readable storage medium connected to the at least one computeror processor, and a network interface that enables the at least computeror processor to communicate with other nodes in a network.

The process claims set forth hereinafter should not be construed torequire that the steps recited therein be performed in alphabeticalorder (any alphabetical ordering in the claims is used solely for thepurpose of referencing previously recited steps) or in the order inwhich they are recited unless the claim language explicitly specifies orstates conditions indicating a particular order in which some or all ofthose steps are performed. Nor should the process claims be construed toexclude any portions of two or more steps being performed concurrentlyor alternatingly unless the claim language explicitly states a conditionthat precludes such an interpretation.

1. A method for operating a transaction-driven, self-validatingdistributed ledger system comprising a network of multiple nodes,wherein each of first and second nodes, when transacting with each otheror recording the transactions of a hosted transaction party transactingwith another transacting party, can independently broadcast acomplementary contra-transaction such that either of the first andsecond nodes, upon receipt of both contra-transactions, canindependently validate the transactions and update the distributedledger, the method comprising: (a) generating in the first node a firstset of contra-transaction data, including the first node'scontra-transaction block's unique ledger address and hash-link, whichfirst set of contra-transaction data is complementary to a second set ofcontra-transaction data for a transaction, wherein thecontra-transaction data of the first set comprises data overtlyidentifying the first node and covertly identifying the second node,data identifying an asset, data representing an amount of value andother data; (b) generating in the second node the second set ofcontra-transaction data, including the second node's contra-transactionblock's unique ledger address and hash-link, which second set ofcontra-transaction data is complementary to the first set ofcontra-transaction data for the transaction, wherein thecontra-transaction data of the second set comprises data overtlyidentifying the second node and covertly identifying the first node,data identifying the asset and data representing the amount of value andother data; (c) generating in the first node a first private keyencrypted hash of a message comprising the first set of transaction dataas a covert additional matching control; (d) generating in the secondnode a second private key encrypted hash of a message comprising thesecond set of transaction data as a covert additional matching control;(e) sharing the first private key encrypted hash with the second node;(f) sharing the second private key encrypted hash with the first node;(g) generating in the first node delivery contra-transaction data forthe transaction, which delivery contra-transaction data comprises thefirst set of transaction data, including the first node'scontra-transaction block's unique ledger address and hash-link in thefirst node's blockchain, and the second private key encrypted hash anddoes not identify the second node; (h) generating in the second nodereceipt contra-transaction data for the transaction, which receiptcontra-transaction data comprises the second set of transaction data,including the second node's contra-transaction block's unique ledgeraddress and hash-link in the second node's blockchain, and the firstprivate key encrypted hash and does not identify the first node; (i)broadcasting the delivery contra-transaction data to the network; (j)broadcasting the receipt contra-transaction data to the network; (k)receiving the broadcast delivery and receipt contra-transaction data atthe first and second nodes and a third node in the network; (l) matchingthe broadcast delivery and receipt contra-transaction data in one ormore of the first, second and third nodes; (m) validating the deliverycontra-transaction data in the second or third node by decrypting thesecond encrypted hash to generate a first hashed message, hashing thesecond set of transaction data to generate a second hashed message, andmatching the first and second hashed messages; (n) validating thereceipt contra-transaction data in the first or third node by decryptingthe first encrypted hash to generate a third hashed message, hashing thefirst set of transaction data to generate a fourth hashed message, andmatching the third and fourth hashed messages; and (o) posting thedelivery and receipt contra-transaction data to delivery and receipttransaction logs respectively in one or more of the first, second andthird nodes.
 2. The method as recited in claim 1, wherein step (o)comprises: posting the delivery contra-transaction data to a deliverytransaction log in the second or third node referencing the first node'scontra-transaction block's unique ledger address and hash-link in thefirst node's blockchain; posting the receipt contra-transaction data toa receipt transaction log in the first or third node referencing thesecond node's contra-transaction block's unique ledger address andhash-link in the second node's blockchain; and posting some of thedelivery and receipt contra-transaction data to separate and distinctownership logs in one or more of the first, second and third nodes. 3.The method as recited in claim 1, wherein in order to meet a specifiedor unspecified obligation with a ledger-referenced value ornon-ledger-referenced value to be transferred, loaned, borrowed orpledged, the transaction is one of the following types: a transfer, apledge, a loan, a contingent transfer, a short transfer, a shorttransfer fill, a short contingent transfer and a short contingenttransfer fill.
 4. The method as recited in claim 1, further comprising:the first node, referencing the first node's contra-transaction block'sunique ledger address and hash-link in the first node's blockchain,posts the delivery contra-transaction data to a blockchain transactionlog in the first node prior to step (i); the first node, referencing thesecond node's contra-transaction block's unique ledger address andhash-link in the second node's blockchain, posts the receiptcontra-transaction data to a replicated copy of a blockchain transactionlog of the second node subsequent to step (i); updating an ownership login the first node to reflect changes in asset ownership resulting fromthe transaction subsequent to step (i); the second node, referencing thesecond node's contra-transaction block's unique ledger address andhash-link in the second node's blockchain, posts the receiptcontra-transaction data to the blockchain transaction log in the secondnode prior to step (j); the second node, referencing the first node'scontra-transaction block's unique ledger address and hash-link in thefirst node's blockchain, posts the delivery contra-transaction data to areplicated copy of the blockchain transaction log of the first nodesubsequent to step (j); and updating an ownership log in the second nodeto reflect changes in asset ownership resulting from the transactionsubsequent to step (j).
 5. The method as recited in claim 1, whereineach delivery transaction log has a first fractal lattice structurecomprising fractal lattice addresses and each receipt transaction loghas a second fractal lattice structure comprising fractal latticeaddresses, the method further comprising: identifying a first nextsequential fractal lattice address in the first fractal latticestructure; hash linking the first next sequential fractal latticeaddress to a fractal lattice address in a prior layer of the firstfractal lattice structure; associating the delivery contra-transactiondata with the first next sequential fractal lattice address; identifyinga second next sequential fractal lattice address in the second fractallattice structure; hash linking the second next sequential fractallattice address to a fractal lattice address in a prior layer of thesecond fractal lattice structure; and associating the receiptcontra-transaction data with the second next sequential fractal latticeaddress.
 6. The method as recited in claim 5, wherein step (c) compriseshashing a message comprising the first next sequential fractal latticeaddress, a first node identifier, a second node identifier, an assetidentifier and an amount of value and then encrypting the hashed messageusing a private encryption key of the first node, and step (d) compriseshashing a message comprising the second next sequential fractal latticeaddress, the first node identifier, the second node identifier, theasset identifier and the amount of value and then encrypting the hashedmessage using a private encryption key of the second node.
 7. The methodas recited in claim 1, further comprising maintaining a uniqueblockchain transaction log for the controlled recording of transfers ofvalue into and out of the network.
 8. The method as recited in claim 1,wherein the first and second nodes communicate via scripts, the methodfurther comprising script building and running processes which areprogrammed in machine-readable code of four, parameter-driven sequentialprocess components which are generically combined in variouscombinations to represent any financial services transaction orlife-cycle without the need for infinite loops, wherein the fourcomponents are: (a) a single transfer of one asset; (b) an assetclassification change; (c) a time-driven change in value; and (d) acontingent, dual asset, bi-directional transfer, and wherein therespective parameters for each sequential component are: (a) number,unit and value; (b) timings: single event, periodic events and multiplenon-periodic events; (c) generated events: data, date, state, choice andgain/loss; and (d) primary, secondary and tertiary assets.
 9. A methodfor a multi-hash link, variable, n-dimensional self-validation ofconsistency and completeness on a distributed ledger or database for anetwork of multiple co-equal and participating nodes for single ormultiple parties utilizing machine-readable code to record value,records or information and the transfer thereof between the multipleparties participating in the network on an immutable record, wherebyupdates to the ledger are independently generated by multiple partiesutilizing multiple nodes for updating the ledger and the changes arebroadcast via transaction data and the multiple nodes independentlyvalidate the integrity, completeness and consistency of the ledger withthe transaction data alone without the need to confer with any othernodes or parties for consensus, competitive creation or third-partyvalidation of the ledger, whether they instigated the transaction ornot.
 10. The method as recited in claim 9, wherein the transaction dataof any one node is sequenced utilizing a fractal lattice pattern createdby its own defined equation allowing multiple algorithmicallycalculable, non-recurring, sequential, variable, n-dimensional branchlocations to uniquely assign a data address for referencing uniquetransaction data in a distributed ledger or database for a network ofmultiple nodes for single or multiple parties utilizing machine-readablecode such that the data's address is communicated and used by any othernode in the network to recreate the data and unique address without theneed to confer with the originating node or other nodes in the network.11. The method as recited in claim 10, wherein the fractal patternchosen to create data addresses to be assigned is variable by a formulaof a fractal pattern and is varied from data period to data period aslong as the chosen pattern is communicated to the multiple nodes andparties in the network to allow them to recreate the structure withoutthe need to confer with the originating nodes or parties or other nodesor parties in the network.
 12. The method as recited in claim 10,wherein a data set applied to the unique address is given aclassification of “end” to mark the end of a fractal branch or “last” tomark a last transaction posted in a period so that the completeness ofthe data structure and addresses are communicated and used by any othernode in the network to recreate and confirm the completeness of the datastructure and unique address without the need to confer with theoriginating nodes or parties or other nodes or parties in the network.13. The method as recited in claim 10, further comprising hash-linking adata address to a hash of any prior utilized address in a structured orunstructured way which is referenced in the data address data such thatwhen it is communicated to the network of multiple nodes for multipleparties, any node recreates and validates the hash link to verify theconsistency of the originating nodes data structure without the need toconfer with the originating node or parties or other nodes or partieswithin the network.
 14. The method as recited in claim 9, wherein everytransaction in the network between two or more parties transactingutilizes coded script and securely shares data to agreed scriptparameters and shares transaction security and linking data at one ormore nodes to create contra-transactions on a co-equal basis thatreflect their distinct obligations for transfers or contingent transferssuch that the contra-transactions are linked, validated and matched onecontra-transaction per blockchain block to justify the update ofownership data based on the data of the two contra-transactions alonewithout the need to confer with the originating nodes or parties orother nodes or parties in the network.
 15. The method as recited inclaim 14, wherein across the network two originating nodes generatedistinct and unique private key encrypted hashes, whereby the hashes arecreated from a set of transaction data fields and transacting nodeidentity is shared and recorded by the originating nodes on a reciprocaltransaction as a means to link the contra-transactions and validate theidentity of the originating nodes and prevent mismatches of identicaltransactions from different counterparties and interference unless thetwo private keys of the originating nodes are known.
 16. The method asrecited in claim 15, whereby mathematical transformations of thetransacting parties public encryption key in conjunction withtransaction data and a random nonce create a unique, confidentialidentifier for every position in an ownership log of the distributedledger or database when it is created, to be posted to the ownership logmaintained by every participating node on the network, thereby onlyrevealing the identity of the transacting parties whenever thetransaction data and nonce are provided to a node which is independentof the nodes of the transacting parties.
 17. The method as recited inclaim 16, whereby a further mathematical transformation of a uniqueidentifier with transaction data and a random nonce are used to createan encumbrance for the value, records or information recorded on thedistributed ledger or database ownership log such that the value canonly be unlocked by the transacting party that knows the transactiondata and random nonce combined with the mathematical transformation. 18.The method as recited in claim 14, whereby two transacting parties viarespective originating nodes process respective contra-transactions fora single asset transfer and then broadcast to the distributed ledger ordatabase network of multiple parties or nodes, whereby thecontra-transactions can be matched and validated by the multiple nodesin the network to update their distributed ledgers or databases in thenetwork to confirm the related update to the ownership log is staged tooccur immediately or at a time or event-driven time in the futurewhether the position transferred is a pledge or a loan, is ledgerreferenced or unreferenced, is specified or unspecified, and isfuture-dated or variable dependent.
 19. The method as recited in claim14, whereby two transacting parties via respective originating nodesprocess respective pairs of contra-transactions for contingent,bi-directional dual asset transfers which are broadcast to thedistributed ledger or database network of multiple parties or nodes,whereby the pairs of contra-transactions are matched and validated bythe multiple nodes in the network to update their distributed ledgers ordatabases of contingent transfers in the network to confirm the relatedcreation and processing of the two pairs of contra-transactions isstaged to occur immediately or at a time or event-driven time in thefuture whether the positions for either of the dual assets transferredare a pledge or a loan, are ledger referenced or unreferenced, arespecified or unspecified, and future-dated or variable dependentposition.
 20. A transaction-driven, self-validating distributed ledgersystem comprising a network of multiple nodes, comprising first, secondand third nodes configured to perform the following operations: (a)generating in the first node a first set of contra-transaction data,including the first node's contra-transaction block's unique ledgeraddress and hash-link, which first set of contra-transaction data iscomplementary to a second set of contra-transaction data for atransaction, wherein the contra-transaction data of the first setcomprises data overtly identifying the first node and covertlyidentifying the second node, data identifying an asset, datarepresenting an amount of value and other data; (b) generating in thesecond node the second set of contra-transaction data, including thesecond node's contra-transaction block's unique ledger address andhash-link, which second set of contra-transaction data is complementaryto the first set of contra-transaction data for the transaction, whereinthe contra-transaction data of the second set comprises data overtlyidentifying the second node and covertly identifying the first node,data identifying the asset and data representing the amount of value andother data; (c) generating in the first node a first private keyencrypted hash of a message comprising the first set of transaction dataas a covert additional matching control; (d) generating in the secondnode a second private key encrypted hash of a message comprising thesecond set of transaction data as a covert additional matching control;(e) sharing the first private key encrypted hash with the second node;(f) sharing the second private key encrypted hash with the first node;(g) generating in the first node delivery contra-transaction data forthe transaction, which delivery contra-transaction data comprises thefirst set of transaction data, including the first node'scontra-transaction block's unique ledger address and hash-link in thefirst node's blockchain, and the second private key encrypted hash anddoes not identify the second node; (h) generating in the second nodereceipt contra-transaction data for the transaction, which receiptcontra-transaction data comprises the second set of transaction data,including the second node's contra-transaction block's unique ledgeraddress and hash-link in the second node's blockchain, and the firstprivate key encrypted hash and does not identify the first node; (i)broadcasting the delivery contra-transaction data to the network; (j)broadcasting the receipt contra-transaction data to the network; (k)receiving the broadcast delivery and receipt contra-transaction data atthe first, second and third nodes in the network; (l) matching thebroadcast delivery and receipt contra-transaction data in one or more ofthe first, second and third nodes; (m) validating the deliverycontra-transaction data in the second or third node by decrypting thesecond encrypted hash to generate a first hashed message, hashing thesecond set of transaction data to generate a second hashed message, andmatching the first and second hashed messages; (n) validating thereceipt contra-transaction data in the first or third node by decryptingthe first encrypted hash to generate a third hashed message, hashing thefirst set of transaction data to generate a fourth hashed message, andmatching the third and fourth hashed messages; and (o) posting thedelivery and receipt contra-transaction data to logs in one or more ofthe first, second and third nodes.
 21. The system as recited in claim20, wherein in order to meet a specified or unspecified obligation witha ledger-referenced value or non-ledger-referenced value to betransferred, loaned, borrowed or pledged, the transaction is one of thefollowing types: a transfer, a pledge, a loan, a contingent transfer, ashort transfer, a short transfer fill, a short contingent transfer and ashort contingent transfer fill.
 22. The system as recited in claim 21,wherein: each of the first, second and third nodes is further configuredto maintain delivery transaction logs having a first fractal latticestructure comprising fractal lattice addresses and receipt transactionlogs having a second fractal lattice structure comprising fractallattice addresses; the first node is further configured to identify afirst next sequential fractal lattice address in the first fractallattice structure, hash link the first next sequential fractal latticeaddress to a fractal lattice address in a prior layer of the firstfractal lattice structure, and associate the delivery contra-transactiondata with the first next sequential fractal lattice address; and thesecond node is further configured to identify a second next sequentialfractal lattice address in the second fractal lattice structure, hashlink the second next sequential fractal lattice address to a fractallattice address in a prior layer of the second fractal latticestructure, and associate the receipt contra-transaction data with thesecond next sequential fractal lattice address.
 23. The method asrecited in claim 22, wherein operation (c) comprises hashing a messagecomprising the first next sequential fractal lattice address, a firstnode identifier, a second node identifier, an asset identifier and anamount of value and then encrypting the hashed message using a privateencryption key of the first node, and operation (d) comprises hashing amessage comprising the second next sequential fractal lattice address,the first node identifier, the second node identifier, the assetidentifier and the amount of value and then encrypting the hashedmessage using a private encryption key of the second node.
 24. A methodfor operating a distributed ledger system comprising a network ofmultiple nodes, comprising: (a) generating a first set of transactiondata for a transaction in a first node in the network, wherein thetransaction data of the first set comprises data identifying the firstnode, data identifying a second node in the network, data identifying anasset, data representing an amount of value and other data; (b)generating a second set of transaction data for the transaction in thesecond node in the network, wherein the transaction data of the secondset comprises data identifying the first and second nodes, dataidentifying the asset and data representing the amount of value andother data; (c) generating a first encrypted hash of a messagecomprising the first set of transaction data in the first node; (d)generating a second encrypted hash of a message comprising the secondset of transaction data in the second node; (e) sharing the firstencrypted hash with the second node; (f) sharing the second encryptedhash with the first node; (g) generating delivery contra-transactiondata for the transaction in the first node, which deliverycontra-transaction data comprises the first set of transaction data andthe second encrypted hash and does not identify the second node; (h)generating receipt contra-transaction data for the transaction in thesecond node, which receipt contra-transaction data comprises the secondset of transaction data and the first encrypted hash and does notidentify the first node; (i) broadcasting the deliverycontra-transaction data to the network; (j) broadcasting the receiptcontra-transaction data to the network; (k) receiving the broadcastdelivery and receipt contra-transaction data at a third node in thenetwork; (l) matching the broadcast delivery and receiptcontra-transaction data in the third node; (m) validating the deliverycontra-transaction data in the third node by decrypting the secondencrypted hash to generate a first hashed message, hashing the secondset of transaction data to generate a second hashed message, andmatching the first and second hashed messages; (n) validating thereceipt contra-transaction data in the third node by decrypting thefirst encrypted hash to generate a third hashed message, hashing thefirst set of transaction data to generate a fourth hashed message, andmatching the third and fourth hashed messages; (o) posting the deliveryand receipt contra-transaction data to delivery and receipt transactionlogs in one or more of the first, second and third nodes, wherein eachdelivery transaction log has a first fractal lattice structurecomprising fractal lattice addresses and each receipt transaction loghas a second fractal lattice structure comprising fractal latticeaddresses; (p) identifying a first next sequential fractal latticeaddress in the first fractal lattice structure; (q) hash linking thefirst next sequential fractal lattice address to a fractal latticeaddress in a prior layer of the first fractal lattice structure; (r)associating the delivery contra-transaction data with the first nextsequential fractal lattice address; (s) identifying a second nextsequential fractal lattice address in the second fractal latticestructure; (t) hash linking the second next sequential fractal latticeaddress to a fractal lattice address in a prior layer of the secondfractal lattice structure; and (u) associating the receiptcontra-transaction data with the second next sequential fractal latticeaddress.
 25. The method as recited in claim 24, wherein step (c)comprises hashing a message comprising the first next sequential fractallattice address, a first node identifier, a second node identifier, anasset identifier and an amount of value and then encrypting the hashedmessage using a private encryption key of the first node, and step (d)comprises hashing a message comprising the second next sequentialfractal lattice address, the first node identifier, the second nodeidentifier, the asset identifier and the amount of value and thenencrypting the hashed message using a private encryption key of thesecond node.
 26. A method for a multi-hash link, variable, n-dimensionalself-validation of consistency and completeness in a database for anetwork of multiple nodes for single or multiple parties utilizingmachine-readable code to record information and the transfer thereofbetween the multiple parties participating in the network on animmutable record, whereby updates to the database by multiple partiesutilizing multiple nodes update the database and broadcast the changesvia transaction data and the multiple nodes validate the integrity,completeness and consistency of the database with the transaction dataalone without the need to confer with any other nodes or parties,whether they instigated the transaction or not, the method comprisingsequencing the transaction data of any one node utilizing a fractallattice pattern created by its own defined equation allowing multiplealgorithmically calculable, non-recurring, sequential, variable,n-dimensional branch locations to uniquely assign a data address forreferencing unique transaction data in the database for the network ofmultiple nodes for single or multiple parties utilizing machine-readablecode such that the data's address is communicated and used by any othernode in the network to recreate the data and unique address without theneed to confer with the originating node or other nodes in the network.27. The method as recited in claim 26, wherein the fractal patternchosen to create data addresses to be assigned is variable by a formulaof a fractal pattern and is varied from data period to data period aslong as the chosen pattern is communicated to the multiple nodes andparties in the network to allow them to recreate the structure withoutthe need to confer with the originating nodes or parties or other nodesor parties in the network.
 28. The method as recited in claim 26,wherein a data set applied to the unique address is given aclassification of “end” to mark the end of a fractal branch or “last” tomark a last transaction posted in a period so that the completeness ofthe data structure and addresses are communicated and used by any othernode in the network to recreate and confirm the completeness of the datastructure and unique address without the need to confer with theoriginating nodes or parties or other nodes or parties in the network.29. The method as recited in claim 26, further comprising hash-linking adata address to a hash of any prior utilized address in a structured orunstructured way which is referenced in the data address data such thatwhen it is communicated to the network of multiple nodes for multipleparties, any node recreates and validates the hash link to verify theconsistency of the originating nodes data structure without the need toconfer with the originating node or parties or other nodes or partieswithin the network.
 30. The method as recited in claim 26, wherein everytransaction in the network between two or more parties transactingutilizes coded script and securely shares data to agreed scriptparameters and shares transaction security and linking data at one ormore nodes to create contra-transactions that reflect their distinctobligations for transfers or contingent transfers such that thecontra-transactions are linked, validated and matched to justify theupdate of ownership data without the need to confer with the originatingnodes or parties or other nodes or parties in the network.
 31. Themethod as recited in claim 30, wherein across the network twooriginating nodes generate distinct and unique private key encryptedhashes, whereby the hashes are created from a set of transaction datafields and transacting node identity is shared and recorded by theoriginating nodes on a reciprocal transaction as a means to link thecontra-transactions and validate the identity of the originating nodesand prevent interference unless the two private keys of the originatingnodes are known.
 32. The method as recited in claim 31, wherebymathematical transformations of the transacting parties publicencryption key in conjunction with transaction data and a random noncecreate a unique, confidential identifier for every position on thedatabase ownership log when it is created, to be posted to the ownershiplog maintained by every participating node on the network, therebyrevealing the identity of the transacting parties whenever thetransaction data and nonce are provided to a node which is independentof the nodes of the transacting parties.
 33. The method as recited inclaim 32, whereby a further mathematical transformation of a uniqueidentifier with transaction data and a random nonce are used to createan encumbrance for the value, records or information recorded on thedatabase ownership log such that the value can only be unlocked by thetransacting party that knows the transaction data and random noncecombined with the mathematical transformation.
 34. The method as recitedin claim 26, whereby two transacting parties via respective originatingnodes process respective contra-transactions for a single transfer andthen broadcast to the database network of multiple parties or nodes,whereby the contra-transactions can be matched and validated by themultiple nodes in the network to update their databases in the networkto confirm the related update to the ownership log is staged to occurimmediately or at a time or event-driven time in the future whether theposition transferred is a pledge or a loan, is ledger referenced orunreferenced, is specified or unspecified, and is future-dated orvariable dependent.
 35. The method as recited in claim 26, whereby twotransacting parties via respective originating nodes process respectivepairs of contra-transactions for contingent, bi-directional dual assettransfers which are broadcast to the distributed database network ofmultiple parties or nodes, whereby the pairs of contra-transactions arematched and validated by the multiple nodes in the network to updatetheir distributed databases of contingent transfers in the network toconfirm the related creation and processing of the two pairs ofcontra-transactions is staged to occur immediately or at a time orevent-driven time in the future whether the positions for either of thedual assets transferred are a pledge or a loan, are ledger referenced orunreferenced, are specified or unspecified, and future-dated or variabledependent position.
 36. A method for electronically recording transfersof assets between first and second parties using a network comprisingfirst and second nodes that communicate via scripts, comprising scriptbuilding and running processes which are programmed in machine-readablecode residing in the first and second nodes, the script building andrunning processes comprising four parameter-driven sequential processcomponents which are generically combined in various combinations torepresent any financial services transaction or life-cycle without theneed for infinite loops, wherein the four components are: (a) a singletransfer of one asset; (b) an asset classification change; (c) atime-driven change in value; and (d) a contingent, dual asset,bi-directional transfer, and wherein the respective parameters for eachsequential component are: (a) number, unit and value; (b) timings:single event, periodic events and multiple non-periodic events; (c)generated events: data, date, state, choice and gain/loss; and (d)primary, secondary and tertiary assets.